WdfRequestCompleteWithInformation bugcheck

NTDEV
1

Hi,

I’ve been tearing my hair out for the last 2 days and cannot for the life
of me get anywhere with this problem…

Using WDK 6001.18002, I’ve got a simple function driver that handles
device IOControl calls (only). The code I have is cut-and-pasted pretty
much as-is from a driver that has been working for 2 years now…

If I use an IOCTL with outBufferLength = 0, all is well.
However, if outBufferLength > 0, I get a bugcheck in
WdfRequestCompleteWithInformation.

In my test case, it’s actually an unhandled IOCTL call that is causing
the problem (though other handled IOCTLs with non-zero outbuffer length
bugcheck as well). In this case my logic calls
WdfRequestCompleteWithInformation (Request, STATUS_INVALID_DEVICE_REQUEST, 0);

“KP” in windebug tells me that Request = 0, and Queue equals a value that
looks suspiciously like an NTSTATUS code. Not sure if that’s the result of
an erroneous stack frame though…

Now, I’ve had all manner of problems getting a system setup that loads
symbols properly. My machine right now is a mess, full of symbols from XP,
XPSP1 and XPSP2, as well as symbols downloaded from the microsoft symbol
server. Nothing I do seems to tell me the exact nature of the bugcheck.

In any case, I can’t get anywhere with this problem. I’m at a complete
loss as what to do next. In the past 2 days I’ve rebooted my machine
perhaps 50 times trying to trace this problem. I’ve tried remote WinDbg
and (local) crash dump analysis. I’m about to give up in defeat…

Can anyone shed any light on this given this description???

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

2

Please send the output of
!analyze -v
and
!wdfkd.wdflogdump (your driver name)

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Mark McDougall
Sent: Tuesday, March 10, 2009 6:43 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfRequestCompleteWithInformation bugcheck

Hi,

I’ve been tearing my hair out for the last 2 days and cannot for the life
of me get anywhere with this problem…

Using WDK 6001.18002, I’ve got a simple function driver that handles
device IOControl calls (only). The code I have is cut-and-pasted pretty
much as-is from a driver that has been working for 2 years now…

If I use an IOCTL with outBufferLength = 0, all is well.
However, if outBufferLength > 0, I get a bugcheck in
WdfRequestCompleteWithInformation.

In my test case, it’s actually an unhandled IOCTL call that is causing
the problem (though other handled IOCTLs with non-zero outbuffer length
bugcheck as well). In this case my logic calls
WdfRequestCompleteWithInformation (Request, STATUS_INVALID_DEVICE_REQUEST, 0);

“KP” in windebug tells me that Request = 0, and Queue equals a value that
looks suspiciously like an NTSTATUS code. Not sure if that’s the result of
an erroneous stack frame though…

Now, I’ve had all manner of problems getting a system setup that loads
symbols properly. My machine right now is a mess, full of symbols from XP,
XPSP1 and XPSP2, as well as symbols downloaded from the microsoft symbol
server. Nothing I do seems to tell me the exact nature of the bugcheck.

In any case, I can’t get anywhere with this problem. I’m at a complete
loss as what to do next. In the past 2 days I’ve rebooted my machine
perhaps 50 times trying to trace this problem. I’ve tried remote WinDbg
and (local) crash dump analysis. I’m about to give up in defeat…

Can anyone shed any light on this given this description???

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

—
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</http:>

3

Doron Holan wrote:

Please send the output of
!analyze -v
and
!wdfkd.wdflogdump (your driver name)

—8<------8<------8<------8<------8<------8<------8<------8<------8<—

*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: 80000003, The exception code that was not handled
Arg2: 8052a5cc, The address that the exception occurred at
Arg3: b5b1aa6c, Trap Frame
Arg4: 00000000

Debugging Details:

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments
are invalid

FAULTING_IP:
nt!KeI386FlatToGdtSelector+6a
8052a5cc cc int 3

TRAP_FRAME: b5b1aa6c – (.trap 0xffffffffb5b1aa6c)
ErrCode = 00000000
eax=00000000 ebx=8a386658 ecx=00000001 edx=00000000 esi=8a032d68 edi=b9e4f148
eip=8052a5cd esp=b5b1aae0 ebp=b5b1ab04 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202
nt!KeI386FlatToGdtSelector+0x6b:
8052a5cd c3 ret
Resetting default scope

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: test.exe

LAST_CONTROL_TRANSFER: from 8a032d68 to 8052a5cd

STACK_TEXT:
b5b1aae4 8a032d68 00000000 00000005 0000000d nt!KeI386FlatToGdtSelector+0x6b
WARNING: Frame IP not in any known module. Following frames may be wrong.
b5b1ab04 b9e16211 c0000010 00000000 8a386658 0x8a032d68
b5b1ab20 b9e16235 c0000010 00000000 b5b1ab4c Wdf01000+0x30211
b5b1ab30 b9dff824 c0000010 00000000 00000000 Wdf01000+0x30235
b5b1ab4c b9dceb7f 8a032d68 75fcd290 c0000010 Wdf01000+0x19824
b5b1ab80 b9e25514 c0000010 75fcd290 00000000
ich6wdog!Ich6wdogEvtIoDeviceControl+0x183
[e:\work\s5a\sw\s5a-sw-kon\ich6wdog\sys\ioctl.c @ 267]
b5b1aba4 b9e26924 75c7a920 75fcd290 00000000 Wdf01000+0x3f514
b5b1abd4 b9e28fb8 75fcd290 8a032d68 8a3856d8 Wdf01000+0x40924
b5b1abf4 b9e2a722 8a385600 b9e50188 8a3856d8 Wdf01000+0x42fb8
b5b1ac10 b9e2b85d 00000000 89d3ac00 8a387230 Wdf01000+0x44722
b5b1ac34 b9e1a665 89d4a008 b5b1ac64 804eeeb1 Wdf01000+0x4585d
b5b1ac40 804eeeb1 8a385c30 89d4a008 806e4410 Wdf01000+0x34665
b5b1ac40 00000000 8a385c30 89d4a008 806e4410 nt!MiDecommitPages+0x310

STACK_COMMAND: kb

FOLLOWUP_IP:
ich6wdog!Ich6wdogEvtIoDeviceControl+183
[e:\work\s5a\sw\s5a-sw-kon\ich6wdog\sys\ioctl.c @ 267]
b9dceb7f ?? ???

FAULTING_SOURCE_CODE:
263:
264: if (!NT_SUCCESS(status))
265: outLength = 0;
266:

267: WdfRequestCompleteWithInformation (Request, status,
(ULONG_PTR)outLength);
268:
269: //TraceEvents(TRACE_LEVEL_INFORMATION, DBG_IOCTLS,
270: // “<– Ich6wdogEvtIoDeviceControl: status %!STATUS!”,
status);
271: }
272:

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: ich6wdog!Ich6wdogEvtIoDeviceControl+183

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ich6wdog

IMAGE_NAME: ich6wdog.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 49b70af8

FAILURE_BUCKET_ID: 0x8E_ich6wdog!Ich6wdogEvtIoDeviceControl+183

BUCKET_ID: 0x8E_ich6wdog!Ich6wdogEvtIoDeviceControl+183

Followup: MachineOwner

—8<------8<------8<------8<------8<------8<------8<------8<------8<—

As for wdflogdump, I can’t for the life of me work out how to get it
working properly for this driver. I had it working for my filter driver a
few days ago, but no amount of ****ing around will make this work!?!

—8<------8<------8<------8<------8<------8<------8<------8<------8<—

0: kd> !load c:\winddk\6001.18002\bin\x86\wdfkd.dll
0: kd> !wdftmffile c:\winddk\6001.18002\tools\tracing\i386\wdf01007.tmf
Set TMF file name is : ‘c:\winddk\6001.18002\tools\tracing\i386\wdf01007.tmf’
0: kd> !wdflogdump ich6wdog
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is:
c:\winddk\6001.18002\tools\tracing\i386\wdf01007.tmf
DBGHELP: C:\Program Files\Debugging Tools for Windows\WDFLDR.SYS - file
not found
DBGHELP: WDFLDR.SYS not found in
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386
DBGENG: WDFLDR.SYS - Image mapping disallowed by non-local path.
DBGENG: WDFLDR.SYS - Partial symbol image load missing image info
DBGHELP: No header for WDFLDR.SYS. Searching for dbg file
DBGHELP:
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\WDFLDR.dbg -
path not found
DBGHELP:
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\SYS\WDFLDR.dbg -
path not found
DBGHELP:
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\symbols\SYS\WDFLDR.dbg

  • path not found
    DBGHELP: C:\WINDOWS\Symbols_NoSP\WDFLDR.dbg - file not found
    DBGHELP: C:\WINDOWS\Symbols_NoSP\SYS\WDFLDR.dbg - file not found
    DBGHELP: C:\WINDOWS\Symbols_NoSP\symbols\SYS\WDFLDR.dbg - path not found
    DBGHELP: C:\WINDOWS\Symbols_SP1\WDFLDR.dbg - file not found
    DBGHELP: C:\WINDOWS\Symbols_SP1\SYS\WDFLDR.dbg - file not found
    DBGHELP: C:\WINDOWS\Symbols_SP1\symbols\SYS\WDFLDR.dbg - path not found
    DBGHELP: C:\WINDOWS\Symbols_SP2\WDFLDR.dbg - file not found
    DBGHELP: C:\WINDOWS\Symbols_SP2\SYS\WDFLDR.dbg - file not found
    DBGHELP: C:\WINDOWS\Symbols_SP2\symbols\SYS\WDFLDR.dbg - path not found
    DBGHELP:
    E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\WDFLDR.dbg -
    file not found
    DBGHELP:
    E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\SYS\WDFLDR.dbg
  • path not found
    DBGHELP:
    E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\symbols\SYS\WDFLDR.dbg
  • path not found
    DBGHELP: .\WDFLDR.dbg - file not found
    DBGHELP: .\SYS\WDFLDR.dbg - path not found
    DBGHELP: .\symbols\SYS\WDFLDR.dbg - path not found
    DBGHELP: WDFLDR.SYS missing debug info. Searching for pdb anyway
    DBGHELP:
    C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\WDFLDR.pdb -
    file not found
    DBGHELP:
    C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\SYS\WDFLDR.pdb -
    file not found
    DBGHELP:
    C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\symbols\SYS\WDFLDR.pdb
  • file not found
    DBGHELP: C:\WINDOWS\Symbols_NoSP\WDFLDR.pdb - file not found
    DBGHELP: C:\WINDOWS\Symbols_NoSP\SYS\WDFLDR.pdb - file not found
    DBGHELP: C:\WINDOWS\Symbols_NoSP\symbols\SYS\WDFLDR.pdb - file not found
    DBGHELP: C:\WINDOWS\Symbols_SP1\WDFLDR.pdb - file not found
    DBGHELP: C:\WINDOWS\Symbols_SP1\SYS\WDFLDR.pdb - file not found
    DBGHELP: C:\WINDOWS\Symbols_SP1\symbols\SYS\WDFLDR.pdb - file not found
    DBGHELP: C:\WINDOWS\Symbols_SP2\WDFLDR.pdb - file not found
    DBGHELP: C:\WINDOWS\Symbols_SP2\SYS\WDFLDR.pdb - file not found
    DBGHELP: C:\WINDOWS\Symbols_SP2\symbols\SYS\WDFLDR.pdb - file not found
    DBGHELP:
    E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\WDFLDR.pdb -
    file not found
    DBGHELP:
    E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\SYS\WDFLDR.pdb
  • file not found
    DBGHELP:
    E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\symbols\SYS\WDFLDR.pdb
  • file not found
    DBGHELP: WDFLDR.pdb - file not found
    *** WARNING: Unable to verify timestamp for WDFLDR.SYS
    *** ERROR: Module load completed but symbols could not be loaded for
    WDFLDR.SYS
    DBGHELP: WDFLDR - no symbols loaded
    hint: Are symbols available for this driver?
    hint: Did you exclude the .sys extension in the drivername parameter?

Could not find ich6wdog in wdfldr client list

—8<------8<------8<------8<------8<------8<------8<------8<------8<—

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

4

Fix your symbols and retry

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Mark McDougall
Sent: Tuesday, March 10, 2009 8:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfRequestCompleteWithInformation bugcheck

Doron Holan wrote:

> Please send the output of
> !analyze -v
> and
> !wdfkd.wdflogdump (your driver name)

—8<------8<------8<------8<------8<------8<------8<------8<------8<—




 Bugcheck Analysis

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: 80000003, The exception code that was not handled
Arg2: 8052a5cc, The address that the exception occurred at
Arg3: b5b1aa6c, Trap Frame
Arg4: 00000000

Debugging Details:
------------------

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments
are invalid

FAULTING_IP:
nt!KeI386FlatToGdtSelector+6a
8052a5cc cc int 3

TRAP_FRAME: b5b1aa6c – (.trap 0xffffffffb5b1aa6c)
ErrCode = 00000000
eax=00000000 ebx=8a386658 ecx=00000001 edx=00000000 esi=8a032d68 edi=b9e4f148
eip=8052a5cd esp=b5b1aae0 ebp=b5b1ab04 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000202
nt!KeI386FlatToGdtSelector+0x6b:
8052a5cd c3 ret
Resetting default scope

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: test.exe

LAST_CONTROL_TRANSFER: from 8a032d68 to 8052a5cd

STACK_TEXT:
b5b1aae4 8a032d68 00000000 00000005 0000000d nt!KeI386FlatToGdtSelector+0x6b
WARNING: Frame IP not in any known module. Following frames may be wrong.
b5b1ab04 b9e16211 c0000010 00000000 8a386658 0x8a032d68
b5b1ab20 b9e16235 c0000010 00000000 b5b1ab4c Wdf01000+0x30211
b5b1ab30 b9dff824 c0000010 00000000 00000000 Wdf01000+0x30235
b5b1ab4c b9dceb7f 8a032d68 75fcd290 c0000010 Wdf01000+0x19824
b5b1ab80 b9e25514 c0000010 75fcd290 00000000
ich6wdog!Ich6wdogEvtIoDeviceControl+0x183
[e:\work\s5a\sw\s5a-sw-kon\ich6wdog\sys\ioctl.c @ 267]
b5b1aba4 b9e26924 75c7a920 75fcd290 00000000 Wdf01000+0x3f514
b5b1abd4 b9e28fb8 75fcd290 8a032d68 8a3856d8 Wdf01000+0x40924
b5b1abf4 b9e2a722 8a385600 b9e50188 8a3856d8 Wdf01000+0x42fb8
b5b1ac10 b9e2b85d 00000000 89d3ac00 8a387230 Wdf01000+0x44722
b5b1ac34 b9e1a665 89d4a008 b5b1ac64 804eeeb1 Wdf01000+0x4585d
b5b1ac40 804eeeb1 8a385c30 89d4a008 806e4410 Wdf01000+0x34665
b5b1ac40 00000000 8a385c30 89d4a008 806e4410 nt!MiDecommitPages+0x310

STACK_COMMAND: kb

FOLLOWUP_IP:
ich6wdog!Ich6wdogEvtIoDeviceControl+183
[e:\work\s5a\sw\s5a-sw-kon\ich6wdog\sys\ioctl.c @ 267]
b9dceb7f ?? ???

FAULTING_SOURCE_CODE:
263:
264: if (!NT_SUCCESS(status))
265: outLength = 0;
266:
> 267: WdfRequestCompleteWithInformation (Request, status,
(ULONG_PTR)outLength);
268:
269: //TraceEvents(TRACE_LEVEL_INFORMATION, DBG_IOCTLS,
270: // “<– Ich6wdogEvtIoDeviceControl: status %!STATUS!”,
status);
271: }
272:

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: ich6wdog!Ich6wdogEvtIoDeviceControl+183

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ich6wdog

IMAGE_NAME: ich6wdog.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 49b70af8

FAILURE_BUCKET_ID: 0x8E_ich6wdog!Ich6wdogEvtIoDeviceControl+183

BUCKET_ID: 0x8E_ich6wdog!Ich6wdogEvtIoDeviceControl+183

Followup: MachineOwner
---------

—8<------8<------8<------8<------8<------8<------8<------8<------8<—

As for wdflogdump, I can’t for the life of me work out how to get it
working properly for this driver. I had it working for my filter driver a
few days ago, but no amount of ing around will make this work!?!

—8<------8<------8<------8<------8<------8<------8<------8<------8<—

0: kd> !load c:\winddk\6001.18002\bin\x86\wdfkd.dll
0: kd> !wdftmffile c:\winddk\6001.18002\tools\tracing\i386\wdf01007.tmf
Set TMF file name is : ‘c:\winddk\6001.18002\tools\tracing\i386\wdf01007.tmf’
0: kd> !wdflogdump ich6wdog
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is:
c:\winddk\6001.18002\tools\tracing\i386\wdf01007.tmf
DBGHELP: C:\Program Files\Debugging Tools for Windows\WDFLDR.SYS - file
not found
DBGHELP: WDFLDR.SYS not found in
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386
DBGENG: WDFLDR.SYS - Image mapping disallowed by non-local path.
DBGENG: WDFLDR.SYS - Partial symbol image load missing image info
DBGHELP: No header for WDFLDR.SYS. Searching for dbg file
DBGHELP:
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\WDFLDR.dbg -
path not found
DBGHELP:
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\SYS\WDFLDR.dbg -
path not found
DBGHELP:
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\symbols\SYS\WDFLDR.dbg
- path not found
DBGHELP: C:\WINDOWS\Symbols_NoSP\WDFLDR.dbg - file not found
DBGHELP: C:\WINDOWS\Symbols_NoSP\SYS\WDFLDR.dbg - file not found
DBGHELP: C:\WINDOWS\Symbols_NoSP\symbols\SYS\WDFLDR.dbg - path not found
DBGHELP: C:\WINDOWS\Symbols_SP1\WDFLDR.dbg - file not found
DBGHELP: C:\WINDOWS\Symbols_SP1\SYS\WDFLDR.dbg - file not found
DBGHELP: C:\WINDOWS\Symbols_SP1\symbols\SYS\WDFLDR.dbg - path not found
DBGHELP: C:\WINDOWS\Symbols_SP2\WDFLDR.dbg - file not found
DBGHELP: C:\WINDOWS\Symbols_SP2\SYS\WDFLDR.dbg - file not found
DBGHELP: C:\WINDOWS\Symbols_SP2\symbols\SYS\WDFLDR.dbg - path not found
DBGHELP:
E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\WDFLDR.dbg -
file not found
DBGHELP:
E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\SYS\WDFLDR.dbg
- path not found
DBGHELP:
E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\symbols\SYS\WDFLDR.dbg
- path not found
DBGHELP: .\WDFLDR.dbg - file not found
DBGHELP: .\SYS\WDFLDR.dbg - path not found
DBGHELP: .\symbols\SYS\WDFLDR.dbg - path not found
DBGHELP: WDFLDR.SYS missing debug info. Searching for pdb anyway
DBGHELP:
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\WDFLDR.pdb -
file not found
DBGHELP:
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\SYS\WDFLDR.pdb -
file not found
DBGHELP:
C:\work\M7I\sw\M7I-sw-WBD\Mk7iBus\sys\objfre_wxp_x86\i386\symbols\SYS\WDFLDR.pdb
- file not found
DBGHELP: C:\WINDOWS\Symbols_NoSP\WDFLDR.pdb - file not found
DBGHELP: C:\WINDOWS\Symbols_NoSP\SYS\WDFLDR.pdb - file not found
DBGHELP: C:\WINDOWS\Symbols_NoSP\symbols\SYS\WDFLDR.pdb - file not found
DBGHELP: C:\WINDOWS\Symbols_SP1\WDFLDR.pdb - file not found
DBGHELP: C:\WINDOWS\Symbols_SP1\SYS\WDFLDR.pdb - file not found
DBGHELP: C:\WINDOWS\Symbols_SP1\symbols\SYS\WDFLDR.pdb - file not found
DBGHELP: C:\WINDOWS\Symbols_SP2\WDFLDR.pdb - file not found
DBGHELP: C:\WINDOWS\Symbols_SP2\SYS\WDFLDR.pdb - file not found
DBGHELP: C:\WINDOWS\Symbols_SP2\symbols\SYS\WDFLDR.pdb - file not found
DBGHELP:
E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\WDFLDR.pdb -
file not found
DBGHELP:
E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\SYS\WDFLDR.pdb
- file not found
DBGHELP:
E:\work\S5A\sw\S5A-sw-KON\ich6wdog\sys\objfre_wxp_x86\i386\symbols\SYS\WDFLDR.pdb
- file not found
DBGHELP: WDFLDR.pdb - file not found
 WARNING: Unable to verify timestamp for WDFLDR.SYS
** ERROR: Module load completed but symbols could not be loaded for
WDFLDR.SYS
DBGHELP: WDFLDR - no symbols loaded
hint: Are symbols available for this driver?
hint: Did you exclude the .sys extension in the drivername parameter?

Could not find ich6wdog in wdfldr client list

—8<------8<------8<------8<------8<------8<------8<------8<------8<—

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

—
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</http:>

5

Doron Holan wrote:

Fix your symbols and retry

I *finally* got wdflogdump to work and found the problem - the bugcheck
happens when outBuffer != NULL and outBufferLen = 0!

Fixing my test app fixes the problem.

I also see that the framework verifier was set to ON in the registry.
Presumably turning this off will prevent my bugcheck…

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

6

You might be hitting a KMDF verifier issue which was fixed in v1.9. the output of !analyze -v with fixed symbols should verify that

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark McDougall
Sent: Tuesday, March 10, 2009 10:34 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfRequestCompleteWithInformation bugcheck

Doron Holan wrote:

Fix your symbols and retry

I *finally* got wdflogdump to work and found the problem - the bugcheck
happens when outBuffer != NULL and outBufferLen = 0!

Fixing my test app fixes the problem.

I also see that the framework verifier was set to ON in the registry.
Presumably turning this off will prevent my bugcheck…

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

—
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</http:>

7

Doron Holan wrote:

You might be hitting a KMDF verifier issue which was fixed in v1.9. the
output of !analyze -v with fixed symbols should verify that

Yes, I found a post talking about a similar problem that was to be fixed
in v1.7… ah… live & learn! :wink:

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

8

Sorry about the wrong version, i did not remember when it was fixed

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Mark McDougall
Sent: Tuesday, March 10, 2009 10:49 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WdfRequestCompleteWithInformation bugcheck

Doron Holan wrote:

> You might be hitting a KMDF verifier issue which was fixed in v1.9. the
> output of !analyze -v with fixed symbols should verify that

Yes, I found a post talking about a similar problem that was to be fixed
in v1.7… ah… live & learn! :wink:

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

—
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</http:>

9

I did not understand the “Fixing my test app fixes the problem”. By not
fixing the test app, you can create a BSOD!!!.

That does not sound right to me. You should fix the driver !!!

Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.

----- Original Message -----
From: “Mark McDougall”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, March 10, 2009 10:33 PM
Subject: Re:[ntdev] WdfRequestCompleteWithInformation bugcheck

> Doron Holan wrote:
>
>> Fix your symbols and retry
>
> I finally got wdflogdump to work and found the problem - the bugcheck
> happens when outBuffer != NULL and outBufferLen = 0!
>
> Fixing my test app fixes the problem.
>
> I also see that the framework verifier was set to ON in the registry.
> Presumably turning this off will prevent my bugcheck…
>
> Regards,
>
> –
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, http:
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266
>
> —
> 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</http:>

10

Prokash Sinha wrote:

I did not understand the “Fixing my test app fixes the problem”. By not
fixing the test app, you can create a BSOD!!!.

That does not sound right to me. You should fix the driver !!!

Yes indeed. The problem is in the wdf verifier - if enabled it bug-checks
if the application passes in an output buffer address but specifies the
length to be zero. Apparently this is fixed in wdf 1.9.

So, there’s not a lot I can do about it in the driver. I fixed the app and
turned off the wdf verifier for good measure.

Regards,

–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>

11

Couple things to tackle first —

  1. If you know how to setup your dev machine, and test machines for kernel
    mode debugging, including proper symbol reference then pehaps you can take a
    dump, bring it under Windbg, resolve the symbols after pointing to the right
    symbol path using the command “.sympath to clear the symapth, then
    ”.sympath+ SRVc:\websymbolshttp://msdl.microsoft.com/download/symbols".
    Then use !sym noisy, then .reload. _just in case you don’t know the
    commands, you can always look at the help of windbg and you can use one of
    the blog topic of my blog ( shameless ads :).

    1) Now do a analyze -v to get the bugcode (resons), and it might even ask
    to use thread switch, context, and stack dump ( read the output from
    analyze -v command carefully.

    2) Once you have that, cut and paste along with the code that is handling
    ioctls.

    3) There are wdf specific windbg’s bang commands that can also help. I’m
    current with those, but someone will sure point out, if you have stack
    traces posted here for some help.

    Well, as if I’ve to sign something !
    Prokash Sinha
    http://prokash.squarespace.com
    Success has many fathers, but failure is an orphan.

    ----- Original Message -----
    From: “Mark McDougall”
    Newsgroups: ntdev
    To: “Windows System Software Devs Interest List”
    Sent: Tuesday, March 10, 2009 6:39 PM
    Subject: [ntdev] WdfRequestCompleteWithInformation bugcheck

    > Hi,
    >
    > I’ve been tearing my hair out for the last 2 days and cannot for the life
    > of me get anywhere with this problem…
    >
    > Using WDK 6001.18002, I’ve got a simple function driver that handles
    > device IOControl calls (only). The code I have is cut-and-pasted pretty
    > much as-is from a driver that has been working for 2 years now…
    >
    > If I use an IOCTL with outBufferLength = 0, all is well.
    > However, if outBufferLength > 0, I get a bugcheck in
    > WdfRequestCompleteWithInformation.
    >
    > In my test case, it’s actually an unhandled IOCTL call that is causing
    > the problem (though other handled IOCTLs with non-zero outbuffer length
    > bugcheck as well). In this case my logic calls
    > WdfRequestCompleteWithInformation (Request, STATUS_INVALID_DEVICE_REQUEST,
    > 0);
    >
    > “KP” in windebug tells me that Request = 0, and Queue equals a value that
    > looks suspiciously like an NTSTATUS code. Not sure if that’s the result of
    > an erroneous stack frame though…
    >
    > Now, I’ve had all manner of problems getting a system setup that loads
    > symbols properly. My machine right now is a mess, full of symbols from XP,
    > XPSP1 and XPSP2, as well as symbols downloaded from the microsoft symbol
    > server. Nothing I do seems to tell me the exact nature of the bugcheck.
    >
    > In any case, I can’t get anywhere with this problem. I’m at a complete
    > loss as what to do next. In the past 2 days I’ve rebooted my machine
    > perhaps 50 times trying to trace this problem. I’ve tried remote WinDbg
    > and (local) crash dump analysis. I’m about to give up in defeat…
    >
    > Can anyone shed any light on this given this description???
    >
    > Regards,
    >
    > –
    > Mark McDougall, Engineer
    > Virtual Logic Pty Ltd, http:
    > 21-25 King St, Rockdale, 2216
    > Ph: +612-9599-3255 Fax: +612-9599-3266
    >
    > —
    > 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</http:>