Coming out of suspend, I get a BSOD in my file system. The dump file
(below) makes it appear that IoVerifyVolume() is paged out. What is an
IRQL of 0xff? IoVerifyVolume() is a IRQL
< DISPATCH_LEVEL function. Did something go so wrong that the dump file is meaningless?
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pagable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 805fec71, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 805fec71, address which referenced memory
Debugging Details:
READ_ADDRESS: 805fec71
CURRENT_IRQL: ff
FAULTING_IP:
nt!IoVerifyVolume+0
805fec71 ?? ???
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
TRAP_FRAME: f845d920 – (.trap fffffffff845d920)
ErrCode = 00000000
eax=8116eb50 ebx=ff106868 ecx=ff76a988 edx=00000000 esi=ff0fc0f0
edi=ff1066d8
eip=805fec71 esp=f845d994 ebp=f845d9d8 iopl=0 nv up di pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010046
nt!IoVerifyVolume:
805fec71 ?? ???
From my observation, 0xff is reported when interrupts are disabled (“cli”
has been used). There is nothing wrong with having IoVerifyVolume paged
out.
Without at least a stack trace, it isn’t very easy to provide much in the
way of suggestion here.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@charter.net [mailto:xxxxx@charter.net]
Sent: Tuesday, April 08, 2003 7:35 PM
To: File Systems Developers
Subject: [ntfsd] IoVerifyVolume() paged out? IRQL == 0xff???
Coming out of suspend, I get a BSOD in my file system. The dump file
(below) makes it appear that IoVerifyVolume() is paged out. What is an
IRQL of 0xff? IoVerifyVolume() is a IRQL
< DISPATCH_LEVEL function. Did something go so wrong that the dump file is
meaningless?
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pagable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 805fec71, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 805fec71, address which referenced memory
Debugging Details:
READ_ADDRESS: 805fec71
CURRENT_IRQL: ff
FAULTING_IP:
nt!IoVerifyVolume+0
805fec71 ?? ???
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
TRAP_FRAME: f845d920 – (.trap fffffffff845d920)
ErrCode = 00000000
eax=8116eb50 ebx=ff106868 ecx=ff76a988 edx=00000000 esi=ff0fc0f0
edi=ff1066d8
eip=805fec71 esp=f845d994 ebp=f845d9d8 iopl=0 nv up di pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010046
nt!IoVerifyVolume:
805fec71 ?? ???
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I haven’t been able to reproduce this BSOD yet, but here’s the stack
trace. My driver’s IRP_MJ_CREATE path threw an exception which attempted
to verify the device and IoVerifyDevice was paged out.
Any ideas on how to stop this from occuring?
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pagable (or completely invalid) address at
an interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 805fec71, memory referenced
Arg2: 000000ff, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 805fec71, address which referenced memory
Debugging Details:
READ_ADDRESS: 805fec71
CURRENT_IRQL: ff
FAULTING_IP:
nt!IoVerifyVolume+0
805fec71 ?? ???
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
TRAP_FRAME: f845d920 – (.trap fffffffff845d920)
ErrCode = 00000000
eax=8116eb50 ebx=ff106868 ecx=ff76a988 edx=00000000 esi=ff0fc0f0
edi=ff1066d8
eip=805fec71 esp=f845d994 ebp=f845d9d8 iopl=0 nv up di pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010046
nt!IoVerifyVolume:
805fec71 ?? ???
Resetting default context
LAST_CONTROL_TRANSFER: from f896f8d2 to 805fec71
STACK_TEXT:
f845d990 f896f8d2 8116eb50 00000000 804d8768 nt!IoVerifyVolume
WARNING: Stack unwind information not available. Following frames may be
wrong.
f845d9d8 f89664fd ff76a988 ff1066d8 8116eb50 MyDriver!VerifyVol+0xa5ac
f845da20 f896677a ff76a988 ff1066d8 80000003 MyDriver!Exception+0x11d7
f845da74 804eca36 ff0fc020 ff1066d8 ff1066d8 MyDriver!Dispatch+0x1454
f845da84 80582ebb 8116eb38 ff709514 f845dc2c nt!IopfCallDriver+0x31
f845db68 8057f6f0 8116eb50 00000000 ff709470 nt!IopParseDevice+0xa4d
f845dbec 80581aba 00000000 f845dc2c 00000040 nt!ObpLookupObjectName+0x56a
f845dc40 80583172 00000000 00000000 00000001 nt!ObOpenObjectByName+0xe9
f845dcbc 8058324e 01d2dfe0 00100001 01d2dff4 nt!IopCreateFile+0x407
f845dd04 80585258 01d2dfe0 00100001 01d2dff4 nt!IoCreateFile+0x36
f845dd44 804da140 01d2dfe0 00100001 01d2dff4 nt!NtOpenFile+0x25
f845dd44 7ffe0304 01d2dfe0 00100001 01d2dff4 nt!KiSystemService+0xc4
01d2e038 00000000 00000000 00000000 00000000
SharedUserData!SystemCallStub+0x4