WDF_VIOLATION during DTM with KMDF 1.7

NTDEV
1

Hi,

In the past, we had a problem with some laptops, that the laptop could not wake up from hibernate if the device was plugged in. It occurred only on specific Vista systems. Our device is a composite device.
We could solve the issue by calling for WdfDeviceInitSetPowerInrush() in add_device cb.

We used Win& DDK to build the driver, i.e. it was built agains KMDF 1.9. We could pass DTM tests just fine.

Now I build out driver with KMDK 1.7, to work-around the reboot on Vista (which is required if we upgrade KMDF).

When running DTM’s “Common Scenario Stress With IO” test with driver built with KMDF 1.7 on Vista SP2 client (with wdf01000.sys ver. 1.7 installed), I get the following bugcheck:

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 00000001, A framework-based driver has timed out during a power operation.
This typically means that the device stack did not set the
DO_POWER_PAGABLE bit and a driver attempted a pagable operation
after the paging device stack was powered down.
Arg2: 81b3cb54, Pointer to a WDF_POWER_ROUTINE_TIMED_OUT_DATA structure.
Arg3: 00000000, Reserved.
Arg4: 88754008, Reserved.

Obviously, the bugcheck is caused because of the call for WdfDeviceInitSetPowerInrush().

However, if I install wdf01000.sys ver. 1.9, and use my drivers that I build with ver. 1.7, I can pass the test with no problem.

Any input about this?

Thanks,
S.

2

You’ve got some sort of basic sequencing/deadlock problem.

Setting DO_POWER_INRUSH to get around this problem doesn’t actually SOLVE the problem… it only happens to coincidentally let you avoid it, due to the way Windows handles power sequencing.

In other words, calling WdfDeviceInitSetPowerInrush was never a real solution, it was just a lucky work-around.

Fortunately for your customers, and for Windows, your luck seems to have run out on at least one test, on at least one platform. The Bug Check looks to me to be entirely legitimate, and is telling you that you need to actually FIX your problem, and not merely eliminate its symptoms by using a random hack.

Sorry… I’m sure that’s not good news to you. But such is the world in which we driver writers live.

Peter
OSR

3

I think you are working around the actual problem. What callback did not return back to kmdf? !wdfkd.wdflogdump and !WDFDEVICE should give you that information and the original stack where you are stuck.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@gmail.com
Sent: September 16, 2010 4:04 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WDF_VIOLATION during DTM with KMDF 1.7

Hi,

In the past, we had a problem with some laptops, that the laptop could not wake up from hibernate if the device was plugged in. It occurred only on specific Vista systems. Our device is a composite device.
We could solve the issue by calling for WdfDeviceInitSetPowerInrush() in add_device cb.

We used Win& DDK to build the driver, i.e. it was built agains KMDF 1.9. We could pass DTM tests just fine.

Now I build out driver with KMDK 1.7, to work-around the reboot on Vista (which is required if we upgrade KMDF).

When running DTM’s “Common Scenario Stress With IO” test with driver built with KMDF 1.7 on Vista SP2 client (with wdf01000.sys ver. 1.7 installed), I get the following bugcheck:

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 00000001, A framework-based driver has timed out during a power operation.
This typically means that the device stack did not set the
DO_POWER_PAGABLE bit and a driver attempted a pagable operation
after the paging device stack was powered down.
Arg2: 81b3cb54, Pointer to a WDF_POWER_ROUTINE_TIMED_OUT_DATA structure.
Arg3: 00000000, Reserved.
Arg4: 88754008, Reserved.

Obviously, the bugcheck is caused because of the call for WdfDeviceInitSetPowerInrush().

However, if I install wdf01000.sys ver. 1.9, and use my drivers that I build with ver. 1.7, I can pass the test with no problem.

Any input about this?

Thanks,
S.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Hi,

It occurred on specific customer’s laptops when I was working onsite. They don’t have neither serial port, nor firewire, hence I couldn’t connect debugger. All I could see is that the laptops couldn’t wake up from hibernate. It took us a lot of time to get it working with an inrush work-around.

My original question is: why WDF 1.7 verifier considers using WdfDeviceInitSetPowerInrush() as a problem, and WDF 1.9 doesn’t? And why on Vista only?

Thanks,
S.

5

The api call itself is not the root cause of the violation, it is your callback which is not returning. It is probably Vista specific for reasons outside of kmdf, ie making an api call or something that no longer blocks post Vista. You obviously have a dmp file, ask for a full km dump and debug your driver.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@gmail.com
Sent: September 16, 2010 8:20 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF_VIOLATION during DTM with KMDF 1.7

Hi,

It occurred on specific customer’s laptops when I was working onsite. They don’t have neither serial port, nor firewire, hence I couldn’t connect debugger. All I could see is that the laptops couldn’t wake up from hibernate. It took us a lot of time to get it working with an inrush work-around.

My original question is: why WDF 1.7 verifier considers using WdfDeviceInitSetPowerInrush() as a problem, and WDF 1.9 doesn’t? And why on Vista only?

Thanks,
S.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

Did you not bother to read my initial reply, or did you not understand my reply?

Because, you know, if you’re not going to read what people are telling you here, it’s probably not a great idea to continue asking questions. You’ll ask… we’ll answer but you won’t read it… you’ll ask again, we’ll answer again but you won’t read it, and on ad infinitum. I’m not sure how that helps you get to a solution.

Peter
OSR

7

Peter,

Did you not bother to read my initial reply, or did you not understand my reply?
I probably didn’t understand your answer, please accept my apology for that.
If the bug check is reasonable and using WdfDeviceInitSetPowerInrush() is not legal from add_device callback (although according to MSDN I didn’t figure that out), why wouldn’t WDF 1.9 assume it as an error?
This is true for all machines I tested the issue on - when having wdf01000.sys 1. on DTM client I do get the bugcheck, and having it from version 1.9 I don’t. I do understand that I’m lucky not to have the bugcheck with 1.9, I just wondered why.

Thanks,
S.

8

Peter Viscarola (OSR) wrote:

Because, you know, if you’re not going to read what
people are telling you here, it’s probably not a great
idea to continue asking questions. You’ll ask… we’ll
answer but you won’t read it… you’ll ask again, we’ll
answer again but you won’t read it, and on ad
infinitum. I’m not sure how that helps you get to a
solution.

Maybe by giving him the answer to the question will help him resolve his driver issue “the right way” by understanding why the power inrush thing masks the behavior.

9

Set power in rush is masking your underlying issue. The do_power_pagable remark in the !analyze -v output is just a guess as to why your callback has not returned (the guess is that you incurred a page fault either through touching pagable memory or pagable code (yours or the kernel) and that once the page fault occurred, we could not service it because paging is now off because your device is not marked power pagable).

The root cause of not returning from hibernate is that in one of your power up callbacks you are not returning back to kmdf and hanging the power up path. Go get the dump, find the callstack with your driver in it and it should be very clear very quickly what you are hanging on

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, September 16, 2010 10:39 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF_VIOLATION during DTM with KMDF 1.7

Peter,

Did you not bother to read my initial reply, or did you not understand my reply?
I probably didn’t understand your answer, please accept my apology for that.
If the bug check is reasonable and using WdfDeviceInitSetPowerInrush() is not legal from add_device callback (although according to MSDN I didn’t figure that out), why wouldn’t WDF 1.9 assume it as an error?
This is true for all machines I tested the issue on - when having wdf01000.sys 1. on DTM client I do get the bugcheck, and having it from version 1.9 I don’t. I do understand that I’m lucky not to have the bugcheck with 1.9, I just wondered why.

Thanks,
S.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

10

> In the past, we had a problem with some laptops, that the laptop could not wake up from hibernate if

the device was plugged in

So, it hangs.

To debug a hang, make a dump (google for CrashOnCtrlScroll), then open the dump with “windbg -z” and use !stacks or !process 0 7 to look at all call stacks - including the hung thread.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com