In the process of running the surprise removal test on a driver and though the driver functions, under this test it fails; always under Windows 8.1. The function driver I am testing uses a custom bus driver which handles its creation and configuration, thus it is not a driver that can just be arbitrarily loaded. This surprise removal test employs some dark magic and it is able to bring the device back, configured. However when this occurs, the bus driver gets the notification and successfully establishes an IoTarget to it (the function driver), but from that point on the bus driver can not successfully call WdfIoTargetFormatRequestForInternalIoctl(). The call always returns STATUS_REQUEST_NOT_ACCEPTED. The wdflogdump shows that the error stems from FxRequestBase::ValidateTarget:362, which leans towards a failure due to there not being enough stack locations; which in reality there are.
So, my questions are:
- This function driver does use a WDM driver library and as a result the FDO needs to increase the stack size by 1 so that a completion routine can be set for requests which are passed down to it. Question: Is the “magick” that occurs in this test somehow invalidating the stack size adjustment? Though I have added additional logging to confirm the stack size is the expected size.
- Performing the equivalent test under Windows 10 succeeds (and your question is probably so why am I wasting everyone’s time regarding Windows 8… Answer: Our stats show it makes up 2% of our customer base. Management will not let me ask them: WHY???) Does this further validate question 1? Using the recently release WDF source in the debugger seems to only be a Windows 10+ feature, and I have not yet been able to make it work my Windows 8 dev test systems, but; the trace logging indicates the error location.
- Have I tunneled myself into trying to find fault with the test itself? or could there really be an issue in the driver?
Both drivers are KMDF, targeting Windows 7 using KMDF v1.11 built using VS 2017 (while wearing my favorite shirt)
Relevant trace logs:
1668: FxRequest::GetDeviceControlOutputMemoryObject - WDFREQUEST 0x0000307E9DED1198 IOCTL output buffer length is zero, 0xc0000023(STATUS_BUFFER_TOO_SMALL)
1669: FxIoTargetFormatIoctl - enter: WDFIOTARGET 0x0000307E9DB9D228, WDFREQUEST 0x0000307E9DED1198, IOCTL 0x55ff9c04, internal 1, input WDFMEMORY 0x0000307E9DED10C1, output WDFMEMORY 0x0000000000000000
1670: FxRequestBase::ValidateTarget - Cannot reallocate PIRP for WDFREQUEST 0000307E9DED1198 using WDFIOTARGET 0000307E9DB9D228, 0xc00000d0(STATUS_REQUEST_NOT_ACCEPTED)
1671: FxIoTargetFormatIoctl - Exit WDFIOTARGET 0x0000307E9DB9D228, WDFREQUEST 0x0000307E9DED1198, 0xc00000d0(STATUS_REQUEST_NOT_ACCEPTED)
1672: FxRequest::Complete - Completing WDFREQUEST 0x0000307E9DED1198 for IRP 0xFFFFCF8162586CA0 with Information 0x0, 0xc00000d0(STATUS_REQUEST_NOT_ACCEPTED)
Another interesting piece of information is that when this occurs, calls into the WDM library fail with STATUS_INVALID_DEVICE_STATE, which is something else that leads me the “magic” going on in this test.