Forum Discussion
Sleep and PNP Fails on ARM
Issue Summary
I'm trying to certify a https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/ driver with HLK tests where the client is ARM64.
Because Microsoft's documentation states that physical hardware must be used, I purchased a https://www.microsoft.com/en-us/store/configure/surface-laptop-13-inch/8mzbmmcjzqv3.
All the tests pass fine, except the https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/6bd51c1b-3dad-4a5e-b46d-98c2fe91d1aa test.
Parameters used
| Parameter Name | Value |
| DQ | DriverBinaryNames='myDriver.sys' |
| Wpa2skAesSsid | kistestssid |
| Wpa2PskPassword | password |
| ResumeDelay | 10 |
| WDTFREMOTESYSTEM | |
| TestCycles | 4 |
| IOPeriod | 1 |
| DriverVerifierAdditionalDrivers | MSDMFilt.sys |
| FSMFApiTest | TRUE |
| LogDriverVerifierEventsAsFailure | FALSE |
Key Observations
- This test passes fine when certifying for x86_64.
- For ARM64 Virtual Machine, test passes.
- For ARM64 (Physical device), the test fails every time.
- When targeting another driver (not my own) `WDFILTER.sys` the test fails with the same symptoms
- When targeting Microsoft's sample driver [passThrough](https://github.com/microsoft/Windows-driver-samples/tree/main/filesys/miniFilter/passThrough) the test fails with the same symptoms
- The tests will pass fine with the TestCycle parameter set to `3`. It always fails when set to the default `4` cycles.
Errors/Warnings
- HLK Studio typically states that the test failed due to an unexpected reboot
- The client device's event viewer system logs show several instances of this log: Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: TE.ProcessHost.exe (6136) consumed 63349456896 bytes, MsMpEng.exe (5332) consumed 301400064 bytes, and HLKAcmengine.exe (6944) consumed 116539392 bytes.
- There are more logs regarding memory usage such as: `The Client License Service (ClipSVC) failed to start due to insufficient memory resources.`
- Right before the test fails, an error appears on the client where the `TE.ProcessHost.exe` process says: breakpoint reached
- The CMD prompt on the client right before the test fails will often show: `crash with exception code 0xC000027B occurred in module "TextInputHost.exe"`
Question
The above observations and errors/warnings seem to point to either the device or the test itself being the issue.
I've factory reset the laptop already and also created a fresh .vhlk to use in Hyper-V but the outcome is the same.
What is the root cause of the error? Is this a known problem? Can I workaround the problem? Is the problem the test or my device?
1 Reply
- Paul_Eze
Microsoft
Thanks for the detailed repro information. The comparison across x64, ARM64 VM, ARM64 physical hardware, another filter driver, and Microsoft's passThrough sample is important because it suggests the failure may not be specific to your minifilter implementation. The low-memory events from TE.ProcessHost, the unexpected reboot, and the fact that the failure appears on the fourth test cycle are the strongest signals to include in the support case.
I would not conclude from the public thread alone whether this is a device issue, test reliability issue, or environment issue. Please route this through the HLK certification support path with the HLK job logs, system event logs around the reboot, exact HLK kit/version, ARM64 device details, and non-sensitive excerpts showing the TE.ProcessHost memory/breakpoint sequence.
