IRP Cancelation of a Queued Request: what should I expect?

OSR_Community_User · July 12, 2008, 9:05pm

Hi,

I’m new to kmdf and I’m experiencing a problem probably with cancellation and I need some help interpreting the debug info.

My driver is a hid minidriver (so it’s a filter) and, as such, its main job is handling and responding to internal read ioctls. The hidclass driver always has 2 outstanding IRPs (ping pong). My driver handles them by unqueuing automatically (callback) and enqueuing them into a queue that is handled manually: when I have data to send back, the driver unqueues manually one request and completes it then the hidclass sends another one and it goes on like that.

When the system is shutting down, the hidclass driver tries to complete a REMOVE_DEVICE irp and during that process it cancels the ping pong irps or at least it tries to. Right after issuing the IoCancelIrp it calls a KeWaitForSingleObject (supposedly to wait for the Irp to return) but this never happens and the system hangs waiting for these irps to complete.

Now, these 2 irps are actually handled by the kmdf as requests and they are queued into a manual queue. Since kmdf has control on them I’d expect it to complete them automatically and release them since they are queued.
Is it correct to assume that? Does the fact the queue is manual make any difference?

Using the kernel debugger I found the irps and they seem to be just held unprocessed by the driver (MyHidMini) and they seem to be flagged as pending.

Irp is active with 3 stacks 2 is current (= 0x86383adc)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace. Pending has been returned
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[f, 0] 0 1 86352798 00000000 00000000-00000000 pending
\Driver\MyHidMini
Args: 00000008 00000000 000b000b 00000000
[f, 0] 0 e0 86354538 00000000 ee2a9eca-86354604 Success Error Cancel
\Driver\hidkmdf HIDCLASS!HidpInterruptReadComplete
Args: 00000008 00000000 000b000b 00000000

Can anybody help me?

Thanks a lot,
Stra

Mark_Roddy · July 13, 2008, 10:16am

Unless you called WdfRequestMarkCancelable on the requests when processing
them and putting them on your manual queue, they should be processed by KMDF
and cancelled without your having to do anything else. You could register a
cancel event notification callback routine to validate that these requests
are in fact being cancelled, although it sounds like you have already used
the debugger to verify this. (See *EvtIoCanceledOnQueue* ).

On Sat, Jul 12, 2008 at 9:06 PM, wrote:

> Hi,
>
> I’m new to kmdf and I’m experiencing a problem probably with cancellation
> and I need some help interpreting the debug info.
>
> My driver is a hid minidriver (so it’ s a filter) and, as such, its main
> job is handling and responding to internal read ioctls. The hidclass driver
> always has 2 outstanding IRPs (ping pong). My driver handles them by
> unqueuing automatically (callback) and enqueuing them into a queue that is
> handled manually: when I have data to send back, the driver unqueues
> manually one request and completes it then the hidclass sends another one
> and it goes on like that.
>
> When the system is shutting down, the hidclass driver tries to complete a
> REMOVE_DEVICE irp and during that process it cancels the ping pong irps or
> at least it tries to. Right after issuing the IoCancelIrp it calls a
> KeWaitForSingleObject (supposedly to wait for the Irp to return) but this
> never happens and the system hangs waiting for these irps to complete.
>
> Now, these 2 irps are actually handled by the kmdf as requests and they are
> queued into a manual queue. Since kmdf has control on them I’d expect it to
> complete them automatically and release them since they are queued.
> Is it correct to assume that? Does the fact the queue is manual make any
> difference?
>
> Using the kernel debugger I found the irps and they seem to be just held
> unprocessed by the driver (MyHidMini) and they seem to be flagged as
> pending.
>
> Irp is active with 3 stacks 2 is current (= 0x86383adc)
> No Mdl: No System Buffer: Thread 00000000: Irp stack trace. Pending has
> been returned
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> >[f, 0] 0 1 86352798 00000000 00000000-00000000 pending
> \Driver\MyHidMini
> Args: 00000008 00000000 000b000b 00000000
> [f, 0] 0 e0 86354538 00000000 ee2a9eca-86354604 Success Error Cancel
> \Driver\hidkmdf HIDCLASS!HidpInterruptReadComplete
> Args: 00000008 00000000 000b000b 00000000
>
> Can anybody help me?
>
> Thanks a lot,
> Stra
>
> —
> 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
>

–
Mark Roddy

OSR_Community_User · July 13, 2008, 11:05am

Hi Mark,

yes, I actually tried to set the CanceledOnQueue callback which doesn’t get called.
One question though: you said “unless you called WdfRequestMarkCancelable” which I didn’t in fact (since documentation clearly says not to do it in case of queueing in a different queue). What would imply calling that before queueing a request anyway?

Another quick question related to debugging: I realized I don’t have symbols for wdf01000.sys and I could not find them neither in the WDK downloadable from microsoft connect nor they appear available in the symbol server. Do you happen to know anything about this?

Thanks,
Stra.

Mark_Roddy · July 13, 2008, 1:07pm

Assuming that you have done everything correctly (always a bad assumption
for new code, but…) the obvious explanation from the evidence presented is
that these requests are not being cancelled by kmdf. I assume you are
following the source code model from the 6001 WDK. That model also uses a
manual queue for the pended read irps, and it seems to think that it doesn’t
need to do anything special either. Perhaps this is broken from day one for
some reason?

The symbols should be on the public symbol server. We outside redmond devs
have accepted that the source code is never going to get made public, but
not having the symbols up is nonsense. I assume windbg is finding other
kernel symbols on the public symbol server?

On Sun, Jul 13, 2008 at 11:06 AM, wrote:

> Hi Mark,
>
> yes, I actually tried to set the CanceledOnQueue callback which doesn’t get
> called.
> One question though: you said “unless you called WdfRequestMarkCancelable”
> which I didn’t in fact (since documentation clearly says not to do it in
> case of queueing in a different queue). What would imply calling that before
> queueing a request anyway?
>
> Another quick question related to debugging: I realized I don’t have
> symbols for wdf01000.sys and I could not find them neither in the WDK
> downloadable from microsoft connect nor they appear available in the symbol
> server. Do you happen to know anything about this?
>
> Thanks,
> Stra.
>
> —
> 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
>

–
Mark Roddy

raj_r · July 13, 2008, 1:23pm

On 7/13/08, Mark Roddy wrote:
, but
> not having the symbols up is nonsense. I assume windbg is finding other
> kernel symbols on the public symbol server?

well windbg cant find its own dbgeng.dll’s pdb for several months now
iirc the latest version of windbg was released months back

i frequently run into chaining windbg on windbg etc and not having
dbgeng pdb for windbg is kinda pain (i am forced to dig up some old
windbg and its dbgeng.pdb and keep playing with it

so yes symbol files can go missing for a lot of time

0:000> .reload /f
Reloading current modules
…ERROR: Symbol file could not be found. Defaulted to export
symbols for C:\Program Files\Debugging Tools for Windows
(x86)\dbgeng.dll -
…
0:000> version

snip

Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.

command line: '“C:\Program Files\Debugging Tools for Windows
(x86)\windbg.exe” ’ Debugger Process 0xBE0
dbgeng: image 6.9.0003.113, built Fri Mar 21 06:59:34 2008
[path: C:\Program Files\Debugging Tools for Windows (x86)\dbgeng.dll]

0:000> !sym noisy
noisy mode - symbol prompts on
0:000> .reload /f
Reloading current modules

SYMSRV: F:\SYMBOLS\dbgeng.pdb\BEBC7A8E867B48EBA1E5AF454FD3E5171\dbgeng.pdb
not found
SYMSRV: HTTP://MSDL.MICROSOFT.COM/DOWNLOAD/SYMBOLS/dbgeng.pdb/BEBC7A8E867B48EBA1E5AF454FD3E5171/dbgeng.pdb
not found
DBGHELP: C:\Program Files\Debugging Tools for Windows (x86)\dbgeng.pdb
- file not found
DBGHELP: dbgeng.pdb - file not found
ERROR: Symbol file could not be found. Defaulted to export
symbols for C:\Program Files\Debugging Tools for Windows
(x86)\dbgeng.dll -
DBGHELP: dbgeng - export symbols
.
DBGHELP: dbghelp - public symbols
F:\SYMBOLS\dbghelp.pdb\C583B473F0C74FDBA4E3AE8C7BD0FA981\dbghelp.pdb

regards

raj_r

OSR_Community_User · July 13, 2008, 5:24pm

Hi Mark,

yes I’m actually using the same model as the hidusbfx2 sample. The only difference (which should actually make things simpler) is that my driver doesn’t deal with any physical device and it’s root-enumerated.
At some point I thought that this problem had something to do with pnp management but I pretty much tried everything possible but nothing really worked.
Anyway I’ll dig a little more… one way or the other I’m sure I’ll make it work

As for the symbols, the symbol server seems to work for everything else but wdf01000. One thing I really don’t understand is that at some point, apparently (from very old posts), some symbols were available for download with some distribution of WDF. From what I can see from “microsoft connect” there’s only the latest version available and no symbols come with it which I think as a non sense in itself since the same person who is going to need the WDK will be likely going to need the symbols…
May be they are available from MSDN… I don’t know.

Thank you guys for your reply,
Stra.

Mark_Roddy · July 14, 2008, 9:29am

Perhaps one of the msft kmdf people will respond. The fact that you tried
setting an *EvtIoCanceledOnQueue *notification callback and that did not get
called is odd.

One thought I had would be to add an EvtReleaseHardware handler, which
should be invoked on the dispatch remove processing, and purge your queue
yourself.

Also - does remove processing work outside of shutdown? (disable device from
dev manager or simulate surprise removal).

On Sun, Jul 13, 2008 at 5:25 PM, wrote:

> Hi Mark,
>
> yes I’m actually using the same model as the hidusbfx2 sample. The only
> difference (which should actually make things simpler) is that my driver
> doesn’t deal with any physical device and it’s root-enumerated.
> At some point I thought that this problem had something to do with pnp
> management but I pretty much tried everything possible but nothing really
> worked.
> Anyway I’ll dig a little more… one way or the other I’m sure I’ll make it
> work
>
> As for the symbols, the symbol server seems to work for everything else but
> wdf01000. One thing I really don’t understand is that at some point,
> apparently (from very old posts), some symbols were available for download
> with some distribution of WDF. From what I can see from “microsoft connect”
> there’s only the latest version available and no symbols come with it which
> I think as a non sense in itself since the same person who is going to need
> the WDK will be likely going to need the symbols…
> May be they are available from MSDN… I don’t know.
>
> Thank you guys for your reply,
> Stra.
>
> —
> 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
>

–
Mark Roddy

Doron_Holan · July 14, 2008, 1:04pm

This should work, otherwise the sample is fundamentally broken ;). Unfortunately EvtReleaseHardware would be called only after hidclass has canceled the ping pongs. One thing you could do is set a wdm preprocess for internal IOCTL which set a completion routine, copied to the next stack location and then dispatched it back to the framework. This way you can see when the queue is completing the request when canceled. Perhaps there is a weird interaction with the NTSTATUS value being returned or something like that.

As for the symbols, we checked last week and they are on the public symbol server. Are you sure that “srv*http://msdl.microsoft.com/download/symbols” is a part of you sym path? What is the output of !lmi wdf01000? Perhaps you have a prerelease version on your machine. Also, try !sym noisy and then reloading wdf01000 symbols to see what is happening.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, July 14, 2008 6:29 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IRP Cancelation of a Queued Request: what should I expect?

Perhaps one of the msft kmdf people will respond. The fact that you tried setting an EvtIoCanceledOnQueue notification callback and that did not get called is odd.

One thought I had would be to add an EvtReleaseHardware handler, which should be invoked on the dispatch remove processing, and purge your queue yourself.

Also - does remove processing work outside of shutdown? (disable device from dev manager or simulate surprise removal).
On Sun, Jul 13, 2008 at 5:25 PM, > wrote:
Hi Mark,

yes I’m actually using the same model as the hidusbfx2 sample. The only difference (which should actually make things simpler) is that my driver doesn’t deal with any physical device and it’s root-enumerated.
At some point I thought that this problem had something to do with pnp management but I pretty much tried everything possible but nothing really worked.
Anyway I’ll dig a little more… one way or the other I’m sure I’ll make it work

As for the symbols, the symbol server seems to work for everything else but wdf01000. One thing I really don’t understand is that at some point, apparently (from very old posts), some symbols were available for download with some distribution of WDF. From what I can see from “microsoft connect” there’s only the latest version available and no symbols come with it which I think as a non sense in itself since the same person who is going to need the WDK will be likely going to need the symbols…
May be they are available from MSDN… I don’t know.

Thank you guys for your reply,
Stra.

—
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

–
Mark Roddy — 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

OSR_Community_User · July 14, 2008, 5:43pm

regarding the symbols, I have the sympath correctly set on the symbol
server and other symbols load fine.
I’m using WDK 6001.18001 and here is the outcome of the commands you
suggested:

0: kd> !lmi wdf01000
Loaded Module Info: [wdf01000]
Module: wdf01000
Base Address: f5080000
Image Name: wdf01000.sys
Machine Type: 332 (I386)
Time Stamp: 46eb7936 Sat Sep 15 08:18:30 2007
Size: 7c000
CheckSum: 869f3
Characteristics: 102
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 25, 6db50, 6c950 RSDS - GUID:
{E9B826BC-2A96-4585-B4A2-CCD799EEB171}
Age: 1, Pdb: Wdf01000.pdb
Symbol Type: DEFERRED - No error - symbol load deferred
Load Report: no symbols loaded

and then, when I attempt to load my kmdf driver (with !sym noisy)

[…]
SYMSRV: C:\Program Files\Debugging Tools for
Windows\sym\Wdf01000.pdb\E9B826BC2A964585B4A2CCD799EEB1711\Wdf01000.pdb
not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/Wdf01000.pdb/E9B826BC2A964585B4A2CCD799EEB1711/Wdf01000.pdb
not found
DBGHELP: Wdf01000.pdb - file not found
*** ERROR: Module load completed but symbols could not be loaded for
wdf01000.sys
[…]

Actually, from what I can see, the time stamp of wdf01000 is sep 15,
2007 which may be in fact old. I deleted the driver from the drivers32
directory and made sure I’m installing using the latest coinstaller.

Does it make any sense?

Thanks,
Stra

Doron Holan wrote:

This should work, otherwise the sample is fundamentally broken ;).
Unfortunately EvtReleaseHardware would be called only after hidclass has
canceled the ping pongs. One thing you could do is set a wdm preprocess
for internal IOCTL which set a completion routine, copied to the next
stack location and then dispatched it back to the framework. This way
you can see when the queue is completing the request when canceled.
Perhaps there is a weird interaction with the NTSTATUS value being
returned or something like that.

As for the symbols, we checked last week and they are on the public
symbol server. Are you sure that
“srv*http://msdl.microsoft.com/download/symbols” is a part of you sym
path? What is the output of !lmi wdf01000? Perhaps you have a
prerelease version on your machine. Also, try !sym noisy and then
reloading wdf01000 symbols to see what is happening.

d

*From:* xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] *On Behalf Of *Mark Roddy
*Sent:* Monday, July 14, 2008 6:29 AM
*To:* Windows System Software Devs Interest List
*Subject:* Re: [ntdev] IRP Cancelation of a Queued Request: what should
I expect?

Perhaps one of the msft kmdf people will respond. The fact that you
tried setting an /EvtIoCanceledOnQueue /notification callback and that
did not get called is odd.

One thought I had would be to add an EvtReleaseHardware handler, which
should be invoked on the dispatch remove processing, and purge your
queue yourself.

Also - does remove processing work outside of shutdown? (disable device
from dev manager or simulate surprise removal).

On Sun, Jul 13, 2008 at 5:25 PM, > mailto:xxxxx> wrote:
>
> Hi Mark,
>
> yes I’m actually using the same model as the hidusbfx2 sample. The only
> difference (which should actually make things simpler) is that my driver
> doesn’t deal with any physical device and it’s root-enumerated.
> At some point I thought that this problem had something to do with pnp
> management but I pretty much tried everything possible but nothing
> really worked.
> Anyway I’ll dig a little more… one way or the other I’m sure I’ll make
> it work
>
> As for the symbols, the symbol server seems to work for everything else
> but wdf01000. One thing I really don’t understand is that at some point,
> apparently (from very old posts), some symbols were available for
> download with some distribution of WDF. From what I can see from
> “microsoft connect” there’s only the latest version available and no
> symbols come with it which I think as a non sense in itself since the
> same person who is going to need the WDK will be likely going to need
> the symbols…
> May be they are available from MSDN… I don’t know.
>
> Thank you guys for your reply,
> Stra.
>
>
> —
> 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
>
>
>
>
> –
> Mark Roddy — 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
></mailto:xxxxx>

OSR_Community_User · July 14, 2008, 7:14pm

Modification dates are not reliable for this purpose. What does explorer say its version number is?

Good luck,

mm

Stra Ficchio wrote:

regarding the symbols, I have the sympath correctly set on the symbol
server and other symbols load fine.
I’m using WDK 6001.18001 and here is the outcome of the commands you
suggested:

0: kd> !lmi wdf01000
Loaded Module Info: [wdf01000]
Module: wdf01000
Base Address: f5080000
Image Name: wdf01000.sys
Machine Type: 332 (I386)
Time Stamp: 46eb7936 Sat Sep 15 08:18:30 2007
Size: 7c000
CheckSum: 869f3
Characteristics: 102
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 25, 6db50, 6c950 RSDS - GUID:
{E9B826BC-2A96-4585-B4A2-CCD799EEB171}
Age: 1, Pdb: Wdf01000.pdb
Symbol Type: DEFERRED - No error - symbol load deferred
Load Report: no symbols loaded

and then, when I attempt to load my kmdf driver (with !sym noisy)

[…]
SYMSRV: C:\Program Files\Debugging Tools for
Windows\sym\Wdf01000.pdb\E9B826BC2A964585B4A2CCD799EEB1711\Wdf01000.pdb
not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/Wdf01000.pdb/E9B826BC2A964585B4A2CCD799EEB1711/Wdf01000.pdb
not found
DBGHELP: Wdf01000.pdb - file not found
*** ERROR: Module load completed but symbols could not be loaded for
wdf01000.sys
[…]

Actually, from what I can see, the time stamp of wdf01000 is sep 15,
2007 which may be in fact old. I deleted the driver from the drivers32
directory and made sure I’m installing using the latest coinstaller.

Does it make any sense?

Thanks,
Stra

Doron Holan wrote:
> This should work, otherwise the sample is fundamentally broken ;).
> Unfortunately EvtReleaseHardware would be called only after hidclass
> has canceled the ping pongs. One thing you could do is set a wdm
> preprocess for internal IOCTL which set a completion routine, copied
> to the next stack location and then dispatched it back to the
> framework. This way you can see when the queue is completing the
> request when canceled. Perhaps there is a weird interaction with the
> NTSTATUS value being returned or something like that.
>
>
>
> As for the symbols, we checked last week and they are on the public
> symbol server. Are you sure that
> “srv*http://msdl.microsoft.com/download/symbols” is a part of you sym
> path? What is the output of !lmi wdf01000? Perhaps you have a
> prerelease version on your machine. Also, try !sym noisy and then
> reloading wdf01000 symbols to see what is happening.
>
>
>
> d
>
>
>
> *From:* xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] *On Behalf Of *Mark Roddy
> *Sent:* Monday, July 14, 2008 6:29 AM
> *To:* Windows System Software Devs Interest List
> *Subject:* Re: [ntdev] IRP Cancelation of a Queued Request: what
> should I expect?
>
>
>
> Perhaps one of the msft kmdf people will respond. The fact that you
> tried setting an /EvtIoCanceledOnQueue /notification callback and that
> did not get called is odd.
>
>
>
> One thought I had would be to add an EvtReleaseHardware handler, which
> should be invoked on the dispatch remove processing, and purge your
> queue yourself.
>
>
>
> Also - does remove processing work outside of shutdown? (disable
> device from dev manager or simulate surprise removal).
>
> On Sun, Jul 13, 2008 at 5:25 PM, >> mailto:xxxxx> wrote:
>>
>> Hi Mark,
>>
>> yes I’m actually using the same model as the hidusbfx2 sample. The
>> only difference (which should actually make things simpler) is that my
>> driver doesn’t deal with any physical device and it’s root-enumerated.
>> At some point I thought that this problem had something to do with pnp
>> management but I pretty much tried everything possible but nothing
>> really worked.
>> Anyway I’ll dig a little more… one way or the other I’m sure I’ll
>> make it work
>>
>> As for the symbols, the symbol server seems to work for everything
>> else but wdf01000. One thing I really don’t understand is that at some
>> point, apparently (from very old posts), some symbols were available
>> for download with some distribution of WDF. From what I can see from
>> “microsoft connect” there’s only the latest version available and no
>> symbols come with it which I think as a non sense in itself since the
>> same person who is going to need the WDK will be likely going to need
>> the symbols…
>> May be they are available from MSDN… I don’t know.
>>
>> Thank you guys for your reply,
>> Stra.
>>
>>
>> —
>> 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
>>
>>
>>
>>
>> –
>> Mark Roddy — 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
>>
></mailto:xxxxx>

Doron_Holan · July 14, 2008, 7:21pm

I do not think you have KMDF v1.7 on your machine. Here is what my vista sp1 machine says

C:\Windows\System32\drivers>filever Wdf01000.sys
–a-- W32i DRV ENU 1.7.6001.0 shp 503,864 01-18-2008 wdf01000.sys

C:\Windows\System32\drivers>c:\debuggers\symchk.exe /v Wdf01000.sys
[SYMCHK] Searching for symbols to C:\Windows\System32\drivers\Wdf01000.sys in path SRV*C:\Windows\SYMBOLS*http://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: SRV*C:\Windows\SYMBOLS*http://msdl.microsoft.com/download/symbols
DBGHELP: No header for C:\Windows\System32\drivers\Wdf01000.sys. Searching forimage on disk
DBGHELP: C:\Windows\System32\drivers\Wdf01000.sys - OK
DBGHELP: Wdf01000 - public symbols
C:\Windows\SYMBOLS\Wdf01000.pdb\0E5C347DFB5A4B1DB1606D336048C5D11\Wdf01000.pdb
[SYMCHK] MODULE64 Info ----------------------
[SYMCHK] Struct size: 1672 bytes
[SYMCHK] Base: 0x00010000
[SYMCHK] Image size: 507904 bytes
[SYMCHK] Date: 0x47919015
[SYMCHK] Checksum: 0x000831d4
[SYMCHK] NumSyms: 0
[SYMCHK] SymType: SymPDB
[SYMCHK] ModName: Wdf01000
[SYMCHK] ImageName: C:\Windows\System32\drivers\Wdf01000.sys
[SYMCHK] LoadedImage: C:\Windows\System32\drivers\Wdf01000.sys
[SYMCHK] PDB: “C:\Windows\SYMBOLS\Wdf01000.pdb\0E5C347DFB5A4B1DB1606D336048C5D11\Wdf01000.pdb”
[SYMCHK] CV: RSDS
[SYMCHK] CV DWORD: 0x53445352
[SYMCHK] CV Data: Wdf01000.pdb
[SYMCHK] PDB Sig: 0
[SYMCHK] PDB7 Sig: {0E5C347D-FB5A-4B1D-B160-6D336048C5D1}
[SYMCHK] Age: 1
[SYMCHK] PDB Matched: TRUE
[SYMCHK] DBG Matched: TRUE
[SYMCHK] Line nubmers: FALSE
[SYMCHK] Global syms: FALSE
[SYMCHK] Type Info: TRUE
[SYMCHK] ------------------------------------
SymbolCheckVersion 0x00000001
Result 0x00130001
DbgFilename
DbgTimeDateStamp 0x47919015
DbgSizeOfImage 0x0007c000
DbgChecksum 0x000831d4
PdbFilename C:\Windows\SYMBOLS\Wdf01000.pdb\0E5C347DFB5A4B1DB1606D336048C5D11\Wdf01000.pdb
PdbSignature 0x00000000
PdbDbiAge 0x00000001
[SYMCHK] [0x00000000 - 0x00130001] Checked “C:\Windows\System32\drivers\Wdf01000.sys”

Note that my PDB marker is 0E5C347DFB5A4B1DB1606D336048C5D11 while yours is E9B826BC2A964585B4A2CCD799EEB1711

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Stra Ficchio
Sent: Monday, July 14, 2008 2:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IRP Cancelation of a Queued Request: what should I expect?