> While stress-testing my 64 bits driver on an 8 core w7 I got a BSOD and am
not able to see the offending stack. Also I don?t understand why Windbg
seems to enter a sort of 32 bits x86 mode (maybe result of some sort of
corruption?)
My Driver is an Ndis IM driver derived from the NDIS 6 MUX sample.
I see no sign that it has entered 32-bit mode; the instruction, it is
true, is referencing ecx instead of rcx, but it doesn’t much matter;
rcx/ecx is 0, meaning a NULL pointer, which most likely represents a bug
in your code.
I would suggest sprinkling a few ASSERT(p != NULL) for various variables
replacing the p, in critical places in your code where you assume that a
pointer is non-NULL, and wait for one to jump out at you.
The message suggests that a 32-bit user mode program is calling you. Did
you do the suggested .load, and did it change the outcome in any way? And
I mean BEFORE you do the !analyze -v, not AFTER.
Q1) Is there some way to find the offending stack
Q2) What is the prompt ?16.0: kd>? telling? (I?m use to one number for
current processor only)See my WinDbg output:
The context is partially valid. Only x86 user-mode context is available.
The wow64exts extension must be loaded to access 32-bit state.
.load wow64exts will do this if you haven’t loaded it already.
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************Use !analyze -v to get detailed debugging information.
BugCheck D1, {6, 2, 0, fffff8800428b120}
*** ERROR: Module load completed but symbols could not be loaded for
.sys
> Probably caused by : Unknown_Image ( +f120 )
>
> Followup: MachineOwner
> ---------
>
> 16.0: kd:x86> < === Fixed symols for MyDriver === >
> 16.0: kd:x86> !analyze -v
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pageable (or completely invalid) address
> at an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: 0000000000000006, memory referenced
> Arg2: 0000000000000002, IRQL
> Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
> Arg4: fffff8800428b120, address which referenced memory
You have an access check at DISPATCH_LEVEL (IRQL == 2). But it is clearly
a NULL-pointer dereference.
The address 0000000000000006 is a dead giveaway that you passed someone a
NULL pointer.
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 0000000000000006
>
> CURRENT_IRQL: 0
Note that this is in conflict with the previous message about IRQL level,
but it doesn;t matter. An access through a NULL pointer is always an
error, even at PASSIVE_LEVEL.
>
> FAULTING_IP:
> !memcmp+30
> [d:\winmain\minkernel\crts\crtw32\string\amd64\memcmp.asm @ 99]
> fffff8800428b120 8a01 mov al,byte ptr [ecx]<br><br>You are doing a memcmp against a NULL pointer<br><br>><br>> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT<br>><br>> BUGCHECK_STR: 0xD1<br>><br>> LAST_CONTROL_TRANSFER: from 0000000000000000 to 0000000000000000<br>><br>> STACK_TEXT:<br>> 00000000 00000000 00000000 00000000 00000000 0x0<br>><br>><br>> STACK_COMMAND: .bugcheck ; kb<br>><br>> FOLLOWUP_IP:<br>> <mydriver>!memcmp+30<br>> [d:\winmain\minkernel\crts\crtw32\string\amd64\memcmp.asm @ 99]<br>> fffff8800428b120 8a01 mov al,byte ptr [ecx]
>
> SYMBOL_NAME: !memcmp+30
>
> FOLLOWUP_NAME: MachineOwner
>
> IMAGE_NAME: Unknown_Image
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> BUCKET_ID: INVALID_KERNEL_CONTEXT
>
> MODULE_NAME: Unknown_Module
>
> Followup: MachineOwner
> ---------
> 16.0: kd:x86> kv
> ChildEBP RetAddr Args to Child
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 00000000 00000000 00000000 00000000 00000000 0x0
> 16.0: kd:x86> .load wow64exts
> 16.0: kd:x86> !wow64exts.sw
> Switched to 64bit mode
> 16.0: kd> kv
> Child-SP RetAddr : Args to Child
> : Call Site
> 0000000000000000 0000000000000000 : 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 : 0x0
> 16.0: kd> r
> rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
> rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
> rip=0000000000000000 rsp=0000000000000000 rbp=0000000000000000
> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
> r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
> r14=0000000000000000 r15=0000000000000000
> iopl=0 nv up di pl nz na pe nc
> cs=0000 ss=0000 ds=0000 es=0000 fs=0000 gs=0000
> efl=00000000
> 00000000`00000000 ?? ???
>
>
> 16.0: kd> ||
> . 0 64-bit Full kernel dump:
> D:\SharedDir\Test_1\Dumps\BSOD_WhenStressed\MEMORY.DMP
>
> 16.0: kd> !errlog
> errorlog is empty
> 16.0: kd> !dpcs
> CPU Type KDPC Function
> 0: Normal : 0xfffffa80075d4328 0xfffff880014cea00 ndis!ndisInterruptDpc
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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
>
