Hi,
I have a crash reported by a customer and I am unable to diagnose the
problem clearly, because the stack trace is not showing up correctly. I
am sure I have loaded (.reload /v /i /f <drivername.sys>) the symbols
correctly and lm cmd shows that debugger is picking up the symbols from
correct place.
When I try to analyze the crash I get warning stating that “Frame IP not
in any known module. Following frames may be wrong”.
It does show me the symbol in my driver but then stack location points
to somewhere inside the function and I cannot map it to the code.
Below is output from analyze cmd.
Please suggest me on how can I debug the crash and obtain some useful
information from it.
Btw this driver is a Upper Volume Filter.
Bugcheck clearly shows that the driver is trying to write to NULL but
the code path is the function mentioned is very well exposed.
Doing ln on arg4 of bugcheck gives out following output.
0: kd> ln b80b075a
(b80af0c0) scid!scld_shr_close+0x169a | (b80b09f0)
scid!scld_shr_apit_hwm_cb
Is it saying that either it’s scld_shr_close or scld_shr_apit_hwm_cb ?
0: kd> !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: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: b80b075a, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: 00000000
CURRENT_IRQL: 2
FAULTING_IP:
scid!scld_shr_close+169a
b80b075a 8908 mov [eax],ecx
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD1
LAST_CONTROL_TRANSFER: from 00050005 to b80b075a
TRAP_FRAME: b8217c0c – (.trap ffffffffb8217c0c)
ErrCode = 00000002
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=8b5a5850
edi=8b5a5848
eip=b80b075a esp=b8217c80 ebp=b80d6f24 iopl=0 nv up ei pl zr na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
scid!scld_shr_close+0x169a:
b80b075a 8908 mov [eax],ecx
ds:0023:00000000=???
Resetting default scope
STACK_TEXT:
b80d6f24 00050005 00000000 b80d6f30 b80d6f30 scid!scld_shr_close+0x169a
WARNING: Frame IP not in any known module. Following frames may be
wrong.
00000001 00000000 00000000 00000000 00000000 0x50005
FOLLOWUP_IP:
scid!scld_shr_close+169a
b80b075a 8908 mov [eax],ecx
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: scid!scld_shr_close+169a
MODULE_NAME: scid
IMAGE_NAME: scid.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 43c5c77e
STACK_COMMAND: .trap ffffffffb8217c0c ; kb
BUCKET_ID: 0xD1_W_scid!scld_shr_close+169a
Followup: MachineOwner
---------
If art interprets our dreams, the computer executes them in the guise of
programs!</drivername.sys>
This can certainly happen when the symbols are wrong (what do you get
when you enable symbol load debugging using “!sym noisy” and “.reload”?)
Based upon what you’ve shown us here, I’d guess this is a symbol
problem.
The “ln” just looks through the available symbol information (in this
case, likely the public symbols in the PE header) and shows you the
surrounding symbols - the nearest one BELOW that address, and the
nearest one ABOVE that address. With large offsets like this it is
probably the case that the debugger is using public symbols (what does
“lm x” say?)
So even without symbols, you can use the disassembler to look back and
see from whence the value in eax originated. If it was a memory
allocation failure, then you’ll have to go off and look at memory
utilization, that sort of thing (“!vm” and “!memusage” usually do the
trick for me). No need for symbols though to do rudimentary analysis
(e.g, you could see the previous call was a call through a dword pointer
value that turns out to point to ExAllocatePoolWithTag and you never
checked the return value.)
Good luck!
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Harish Arora
Sent: Thursday, January 19, 2006 8:46 PM
To: ntdev redirect
Subject: [ntdev] warning while showing stack text
Hi,
I have a crash reported by a customer and I am unable to diagnose the
problem clearly, because the stack trace is not showing up correctly. I
am sure I have loaded (.reload /v /i /f <drivername.sys>) the symbols
correctly and lm cmd shows that debugger is picking up the symbols from
correct place.
When I try to analyze the crash I get warning stating that “Frame IP not
in any known module. Following frames may be wrong”.
It does show me the symbol in my driver but then stack location points
to somewhere inside the function and I cannot map it to the code.
Below is output from analyze cmd.
Please suggest me on how can I debug the crash and obtain some useful
information from it.
Btw this driver is a Upper Volume Filter.
Bugcheck clearly shows that the driver is trying to write to NULL but
the code path is the function mentioned is very well exposed.
Doing ln on arg4 of bugcheck gives out following output.
0: kd> ln b80b075a
(b80af0c0) scid!scld_shr_close+0x169a | (b80b09f0)
scid!scld_shr_apit_hwm_cb
Is it saying that either it’s scld_shr_close or scld_shr_apit_hwm_cb ?
0: kd> !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: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: b80b075a, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: 00000000
CURRENT_IRQL: 2
FAULTING_IP:
scid!scld_shr_close+169a
b80b075a 8908 mov [eax],ecx
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD1
LAST_CONTROL_TRANSFER: from 00050005 to b80b075a
TRAP_FRAME: b8217c0c – (.trap ffffffffb8217c0c)
ErrCode = 00000002
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=8b5a5850
edi=8b5a5848
eip=b80b075a esp=b8217c80 ebp=b80d6f24 iopl=0 nv up ei pl zr na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
scid!scld_shr_close+0x169a:
b80b075a 8908 mov [eax],ecx
ds:0023:00000000=???
Resetting default scope
STACK_TEXT:
b80d6f24 00050005 00000000 b80d6f30 b80d6f30 scid!scld_shr_close+0x169a
WARNING: Frame IP not in any known module. Following frames may be
wrong.
00000001 00000000 00000000 00000000 00000000 0x50005
FOLLOWUP_IP:
scid!scld_shr_close+169a
b80b075a 8908 mov [eax],ecx
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: scid!scld_shr_close+169a
MODULE_NAME: scid
IMAGE_NAME: scid.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 43c5c77e
STACK_COMMAND: .trap ffffffffb8217c0c ; kb
BUCKET_ID: 0xD1_W_scid!scld_shr_close+169a
Followup: MachineOwner
---------
If art interprets our dreams, the computer executes them in the guise of
programs!
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</drivername.sys>