Driver Delay Effecting Test Application to Hang

NTDEV
1

Dear List,

I modified wdk-umdf-usb-fx2_driver according to the custom device. In order to simulate the delay in the real device hardware, I introduced a small delay in the completion routine of the read and write io.

In the test application, the asynchronous read is performed as below:

gOverlapped.Offset = 0;
gOverlapped.OffsetHigh = 0;
gOverlapped.hEvent = hReadEvent; /* already created event */

ReadFile(hFile, pinBuf, 21, (PULONG)&nBytesRead,
&gOverlapped);

WaitForSingleObject(hReadEvent, 10000);

This is because I want to wait specified amount of time for read operation and come back irrespective of the data availability. When I run the application for the first time, everything works fine. From the second time onwards, the application simply hangs. I tried even with INFINITE timeout and without timeout also.

One observation is that when I run the app for the first time, WDFHOST.exe service is comsuming 99% of CPU according to the task manager.

Somebody kindly the asynchronous read usage in the above code.

Regards.

2

xxxxx@gmail.com wrote:

Dear List,

I modified wdk-umdf-usb-fx2_driver according to the custom device. In order to simulate the delay in the real device hardware, I introduced a small delay in the completion routine of the read and write io.

How did you do that?

In the test application, the asynchronous read is performed as below:

gOverlapped.Offset = 0;
gOverlapped.OffsetHigh = 0;
gOverlapped.hEvent = hReadEvent; /* already created event */

ReadFile(hFile, pinBuf, 21, (PULONG)&nBytesRead,
&gOverlapped);

WaitForSingleObject(hReadEvent, 10000);

You need to check the return code from ReadFile and make sure
GetLastError is ERROR_IO_PENDING before waiting. If the driver
completed the request immediately, there may be nothing to wait for.
Are you resetting the state of the event by hand after your request?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

The delay was in the form of dummy loop. Eg:
for(int i = 0; i < 10000; i++)
{
for(int j = 0; j < 10000; j++)
{
}
}

I am checking the ReadFile return for ERROR_IO_PENDING. First time when I execute, read returns immediately. From second time onwards, the console blocks. When I debug the program the control is returning back normally from the main.

I want to make a point of two things which may help you to guide me in correct path. One is that when I pass gOverlapped structure as NULL, the control is returning back as expected after the timeout value.

Secondly as I mentioned in the previous post, when I ran the app first time, I noticed WUDFHOST.exe process consuming 99% of CPU.

Regards.

4

Answer to the last question.

Since the event was created with manual reset as FALSE, I guess that we need not reset the event state by hand.

Regards.

5

xxxxx@gmail.com wrote:

Answer to the last question.

Since the event was created with manual reset as FALSE, I guess that we need not reset the event state by hand.

You certainly do if you re-use the event.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

Thanks for the responses. The problem is with the dummy loops included to stimulate the delay. When I copied the same loops to some console test application of the Visual Studio, the control is never coming back indicating that the delay is too high. I guess this is the reason why WUDFHOST.exe is consuming 99% of CPU.

When I reduced the number from 100000 to 1000, the control is coming back to the application. Is there any delay call like Sleep that can be used in ddk.

Regards.

7

xxxxx@gmail.com wrote:

Thanks for the responses. The problem is with the dummy loops included to stimulate the delay. When I copied the same loops to some console test application of the Visual Studio, the control is never coming back indicating that the delay is too high. I guess this is the reason why WUDFHOST.exe is consuming 99% of CPU.

When I reduced the number from 100000 to 1000, the control is coming back to the application. Is there any delay call like Sleep that can be used in ddk.

If WUDFHOST is using the CPU, then it must be a UMDF driver, right?
Then why not just use Sleep? You have user-mode APIs at your disposal.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

That really helped. I am well versed with sdk but just adopting to ddk. In the mean process, just got confused between win sdk and ddk apis.

After the sleep usage, the WUDFHOST.exe is behaving normally and not using 98% of CPU. Thanks for the clarifications.

Regards.