*** Fatal System Error: 0x000000d1

NTDEV
1

i’ve already posted mail in this list…
my problem is my driver runs fine with interrupts disabled… but if device
generates interrupt the system crashes…(this happens when i am handling
Ioctls… FastIoctl Entry Point in my driver). However there’s nothing
wrong in the ISR since i’ve put an ASSERT(0) macro as first line in ISR
for me to know for sure that ISR is called. However this is not a
consistent behaviour…

As suggested by members of this list i’ve downloaded the latest WinDbg &
copied my symbols file(VINIC.pdb) in WINNT\Symbols\sys folder.
Now the result of executing ::

!analyze -ve is as shown below… Can anybody please track down the problem
for me… moreover if following doesn’t give adequate information… please
do let me know what else 'am i supposed to do…

VipkHandleIoctls : VIOCTL_UNBINDVI…(Is my routine. called from my
FastIoctl EntryPoint)

MM:***PAGE FAULT AT IRQL > 1 Va ED0644AA, IRQL 9

*** Fatal System Error: 0x000000d1
(0xED0644AA,0x00000009,0x00000000,0xED0644AA)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

*******************************************************************************

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

Use !analyze -v to get detailed debugging information.

BugCheck D1, {ed0644aa, 9, 0, ed0644aa}

*** WARNING: symbols timestamp is wrong 0x3d65d74c 0x3a651aea for
explorer.exe
Probably caused by : VINIC.sys ( VINIC+44aa )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
804a9bcc cc int 3
kd> !analyze -v
*******************************************************************************

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

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: ed0644aa, memory referenced
Arg2: 00000009, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: ed0644aa, address which referenced memory

Debugging Details:

READ_ADDRESS: ed0644aa Nonpaged pool

CURRENT_IRQL: 9

FAULTING_IP:
VINIC+44aa
ed0644aa ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 80438bab to 804a9bcc

STACK_TEXT:
ba789698 80438bab 00000003 ba7896e0 ed0644aa
nt!RtlpBreakWithStatusInstruction
ba7896c8 8043919e 00000003 ed0644aa ed0644aa nt!KiBugCheckDebugBreak+0x31
ba789a54 804c2160 00000000 ed0644aa 00000009 nt!KeBugCheckEx+0x390
ba789a54 ed0644aa 00000000 ed0644aa 00000009 nt!KiTrap0E+0x2a4
WARNING: Frame IP not in any known module. Following frames may be wrong.
ba789ae0 804c3119 817c2b08 815e90e8 804c30ac 0xed0644aa
ba789af8 804c30b9 ba789b00 000000a3 ba789bd0
nt!KiChainedDispatch2ndLvl+0x4d
ba789af8 8049ee04 ba789b00 000000a3 ba789bd0 nt!KiChainedDispatch+0x29
ba789bd0 8055a30b 00000024 00000000 8188b3a8
nt!ObReferenceObjectByHandle+0x2b0
ba789d44 804be60a 00000024 0012f7f4 0012f7f4
nt!NtRequestWaitReplyPort+0x1ed
ba789d44 77f790ff 00000024 0012f7f4 0012f7f4 nt!KiSystemService+0x10a
0012f7ac 77f7a523 00000024 0012f7f4 0012f7f4
NTDLL!ZwRequestWaitReplyPort+0xb
0012f7cc 77e8c896 0012f7f4 00000000 0002021e
NTDLL!CsrClientCallServer+0x92
0012f8b4 77e8c91d 00000007 0012f954 00000021
KERNEL32!WriteConsoleInternal+0xd3
0012f8d0 77e68aee 00000007 0012f954 00000021 KERNEL32!WriteConsoleA+0x16
0012f92c 1000f513 00000007 0012f954 00000021 KERNEL32!WriteFile+0x80
0012fd68 1000f399 00000001 00334010 0000001f 0x1000f513
0012fd80 1000e41c 00000001 00334010 0000001f 0x1000f399
0012fda0 1000acde 10017038 00000028 0012f8b4 0x1000e41c
0012fdbc 10006dce 00000001 10017038 00000028 0x1000acde
0012fde4 10001e82 10013560 00000000 00332828 0x10006dce
0012fe10 10001820 00332782 7ffdf000 00332780 0x10001e82
0012fe24 004023e8 00332782 00000000 004400d0 0x10001820
0012fe38 00401b28 0000002d 00000000 0012fe78 explorer!c_szHotkeys+0x178
0012ff80 004068e3 00000001 00351100 00351128 explorer!string'+0xc 0012ffc0 77e7afff 00000028 0012f8b4 7ffdf000 explorer!string’+0xf
0012fff0 00000000 0040682f 00000000 0000018a
KERNEL32!BaseProcessStart+0x3d

FAILED_INSTRUCTION_ADDRESS:
VINIC+44aa
ed0644aa ?? ???

FOLLOWUP_IP:
VINIC+44aa
ed0644aa ?? ???

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: VINIC+44aa

MODULE_NAME:

IMAGE_NAME: VINIC.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3d84d615

STACK_COMMAND: kb

BUCKET_ID: 0xD1_BAD_IP_VINIC+44aa

Followup: MachineOwner

2

is your ISR in a paged code section?

-p

-----Original Message-----
From: Shailesh [mailto:xxxxx@hotmail.com]
Sent: Monday, September 09, 2002 12:17 PM
To: NT Developers Interest List
Subject: [ntdev] *** Fatal System Error: 0x000000d1

i’ve already posted mail in this list…
my problem is my driver runs fine with interrupts disabled… but if
device generates interrupt the system crashes…(this happens when i am
handling Ioctls… FastIoctl Entry Point in my driver). However there’s
nothing wrong in the ISR since i’ve put an ASSERT(0) macro as first line
in ISR for me to know for sure that ISR is called. However this is not a
consistent behaviour…

As suggested by members of this list i’ve downloaded the latest WinDbg &
copied my symbols file(VINIC.pdb) in WINNT\Symbols\sys folder. Now the
result of executing ::

!analyze -ve is as shown below… Can anybody please track down the
problem for me… moreover if following doesn’t give adequate
information… please do let me know what else 'am i supposed to do…

VipkHandleIoctls : VIOCTL_UNBINDVI…(Is my routine. called from my
FastIoctl EntryPoint)

MM:***PAGE FAULT AT IRQL > 1 Va ED0644AA, IRQL 9

*** Fatal System Error: 0x000000d1
(0xED0644AA,0x00000009,0x00000000,0xED0644AA)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

************************************************************************
*******

*

*
* Bugcheck Analysis

*
*

*
************************************************************************
*******

Use !analyze -v to get detailed debugging information.

BugCheck D1, {ed0644aa, 9, 0, ed0644aa}

*** WARNING: symbols timestamp is wrong 0x3d65d74c 0x3a651aea for
explorer.exe Probably caused by : VINIC.sys ( VINIC+44aa )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
804a9bcc cc int 3
kd> !analyze -v
************************************************************************
*******

*

*
* Bugcheck Analysis

*
*

*
************************************************************************
*******

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is
available get stack backtrace.
Arguments:
Arg1: ed0644aa, memory referenced
Arg2: 00000009, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: ed0644aa, address which referenced memory

Debugging Details:

READ_ADDRESS: ed0644aa Nonpaged pool

CURRENT_IRQL: 9

FAULTING_IP:
VINIC+44aa
ed0644aa ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 80438bab to 804a9bcc

STACK_TEXT:
ba789698 80438bab 00000003 ba7896e0 ed0644aa
nt!RtlpBreakWithStatusInstruction ba7896c8 8043919e 00000003 ed0644aa
ed0644aa nt!KiBugCheckDebugBreak+0x31 ba789a54 804c2160 00000000
ed0644aa 00000009 nt!KeBugCheckEx+0x390 ba789a54 ed0644aa 00000000
ed0644aa 00000009 nt!KiTrap0E+0x2a4
WARNING: Frame IP not in any known module. Following frames may be
wrong. ba789ae0 804c3119 817c2b08 815e90e8 804c30ac 0xed0644aa ba789af8
804c30b9 ba789b00 000000a3 ba789bd0 nt!KiChainedDispatch2ndLvl+0x4d
ba789af8 8049ee04 ba789b00 000000a3 ba789bd0 nt!KiChainedDispatch+0x29
ba789bd0 8055a30b 00000024 00000000 8188b3a8
nt!ObReferenceObjectByHandle+0x2b0
ba789d44 804be60a 00000024 0012f7f4 0012f7f4
nt!NtRequestWaitReplyPort+0x1ed ba789d44 77f790ff 00000024 0012f7f4
0012f7f4 nt!KiSystemService+0x10a 0012f7ac 77f7a523 00000024 0012f7f4
0012f7f4 NTDLL!ZwRequestWaitReplyPort+0xb 0012f7cc 77e8c896 0012f7f4
00000000 0002021e NTDLL!CsrClientCallServer+0x92 0012f8b4 77e8c91d
00000007 0012f954 00000021 KERNEL32!WriteConsoleInternal+0xd3
0012f8d0 77e68aee 00000007 0012f954 00000021 KERNEL32!WriteConsoleA+0x16
0012f92c 1000f513 00000007 0012f954 00000021 KERNEL32!WriteFile+0x80
0012fd68 1000f399 00000001 00334010 0000001f 0x1000f513 0012fd80
1000e41c 00000001 00334010 0000001f 0x1000f399 0012fda0 1000acde
10017038 00000028 0012f8b4 0x1000e41c 0012fdbc 10006dce 00000001
10017038 00000028 0x1000acde 0012fde4 10001e82 10013560 00000000
00332828 0x10006dce 0012fe10 10001820 00332782 7ffdf000 00332780
0x10001e82 0012fe24 004023e8 00332782 00000000 004400d0 0x10001820
0012fe38 00401b28 0000002d 00000000 0012fe78 explorer!c_szHotkeys+0x178
0012ff80 004068e3 00000001 00351100 00351128 explorer!string'+0xc 0012ffc0 77e7afff 00000028 0012f8b4 7ffdf000 explorer!string’+0xf
0012fff0 00000000 0040682f 00000000 0000018a
KERNEL32!BaseProcessStart+0x3d

FAILED_INSTRUCTION_ADDRESS:
VINIC+44aa
ed0644aa ?? ???

FOLLOWUP_IP:
VINIC+44aa
ed0644aa ?? ???

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: VINIC+44aa

MODULE_NAME:

IMAGE_NAME: VINIC.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3d84d615

STACK_COMMAND: kb

BUCKET_ID: 0xD1_BAD_IP_VINIC+44aa

Followup: MachineOwner

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

3

Is there some overwhelming reason to be using the rarely used
FastIoDeviceControl interface? Given that this is hardly ever used by any
driver, maybe you ought to reconsider using it.

The thread that crashed was, it appears, the victim of circumstances and
not the perpetrator of the crime. An interrupt has occurred and borrowed
this thread.

The bugcheck appears to be complaining about accessing the address
0xED0644AA, which purports to be in your driver, as a code segment, while
this address also appears to be bogus. The thread trace is in the midst
of interrupt processing (KiChainedDispatch, KiChainedDispatch2ndLvl) and
it thinks that it ought to be calling some code at 0xed0644aa, which also
appears to be an offset in your driver: VINIC+44aa. IRQL 9 is a very
common mapping for PCI devices. On quite a few platforms running w2k, all
PCI devices are mapped to IRQL 9, that is, yours and everyone elses. You
are sharing interrupts correctly, right?

The calls out of KiChainedDispatch are generally to driver ISR code. Are
you really sure that your ISR is not being invoked here? Is your ISR
doing anything unusual? Are you mucking with interrupt objects in some
non-standard way?

The debugger claims that your driver is loaded at ed060000, is this
correct? Perhaps a map file would help to understand what might be at
VINIC+44aa and might give you some clues about why you are trying to
execute code at this address.

What I find odd is:
READ_ADDRESS: ed0644aa Nonpaged pool

and

ed0644aa ?? ??? <<< I think this is windbg attempting to
read the contents of ed0644aa, and the ‘???’ junk usually means that said
address is not referring to physical memory at this point in time.

I’m not sure how ed0644aa can be both in nonpaged pool and, it appears,
inaccessible. Perhaps you have corrupted nonpaged pool? Or perhaps windbg
is being a bit bogus analyzing the address.

Without access to your dumpfile or your driver symbols I am a bit stumped
about any further analysis. Maybe somebody else will have a clue.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

-----Original Message-----
From: “Shailesh”
To: “NT Developers Interest List”
Date: Mon, 9 Sep 2002 15:17:26 -0400
Subject: [ntdev] Fatal System Error: 0x000000d1

> i’ve already posted mail in this list…
> my problem is my driver runs fine with interrupts disabled… but if
> device
> generates interrupt the system crashes…(this happens when i am
> handling
> Ioctls… FastIoctl Entry Point in my driver). However there’s nothing
> wrong in the ISR since i’ve put an ASSERT(0) macro as first line in ISR
> for me to know for sure that ISR is called. However this is not a
> consistent behaviour…
>
> As suggested by members of this list i’ve downloaded the latest WinDbg
> &
> copied my symbols file(VINIC.pdb) in WINNT\Symbols\sys folder.
> Now the result of executing ::
>
> !analyze -ve is as shown below… Can anybody please track down the
> problem
> for me… moreover if following doesn’t give adequate information…
> please
> do let me know what else 'am i supposed to do…
>
> VipkHandleIoctls : VIOCTL_UNBINDVI…(Is my routine. called from my
> FastIoctl EntryPoint)
>
> MM:PAGE FAULT AT IRQL > 1 Va ED0644AA, IRQL 9
>
> Fatal System Error: 0x000000d1
> (0xED0644AA,0x00000009,0x00000000,0xED0644AA)
>
> Break instruction exception - code 80000003 (first chance)
>
> A fatal system error has occurred.
> Debugger entered on first try; Bugcheck callbacks have not been
> invoked.
>
> A fatal system error has occurred.
>
>**
>
>
> *
>
>
> * Bugcheck Analysis
>
>
> *
>
>
>
> *****
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck D1, {ed0644aa, 9, 0, ed0644aa}
>
> WARNING: symbols timestamp is wrong 0x3d65d74c 0x3a651aea for
> explorer.exe
> Probably caused by : VINIC.sys ( VINIC+44aa )
>
> Followup: MachineOwner
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
> 804a9bcc cc int 3
> kd> !analyze -v
> ***************************************************************
>
>
> *
>
> *
> * Bugcheck Analysis
>
> *
> *
>
> *
> ***************************************************************
>
>
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> 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 kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: ed0644aa, memory referenced
> Arg2: 00000009, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: ed0644aa, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: ed0644aa Nonpaged pool
>
> CURRENT_IRQL: 9
>
> FAULTING_IP:
> VINIC+44aa
> ed0644aa ?? ???
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> LAST_CONTROL_TRANSFER: from 80438bab to 804a9bcc
>
> STACK_TEXT:
> ba789698 80438bab 00000003 ba7896e0 ed0644aa
> nt!RtlpBreakWithStatusInstruction
> ba7896c8 8043919e 00000003 ed0644aa ed0644aa
> nt!KiBugCheckDebugBreak+0x31
> ba789a54 804c2160 00000000 ed0644aa 00000009 nt!KeBugCheckEx+0x390
> ba789a54 ed0644aa 00000000 ed0644aa 00000009 nt!KiTrap0E+0x2a4
> WARNING: Frame IP not in any known module. Following frames may be
> wrong.
> ba789ae0 804c3119 817c2b08 815e90e8 804c30ac 0xed0644aa
> ba789af8 804c30b9 ba789b00 000000a3 ba789bd0
> nt!KiChainedDispatch2ndLvl+0x4d
> ba789af8 8049ee04 ba789b00 000000a3 ba789bd0 nt!KiChainedDispatch+0x29
> ba789bd0 8055a30b 00000024 00000000 8188b3a8
> nt!ObReferenceObjectByHandle+0x2b0
> ba789d44 804be60a 00000024 0012f7f4 0012f7f4
> nt!NtRequestWaitReplyPort+0x1ed
> ba789d44 77f790ff 00000024 0012f7f4 0012f7f4 nt!KiSystemService+0x10a
> 0012f7ac 77f7a523 00000024 0012f7f4 0012f7f4
> NTDLL!ZwRequestWaitReplyPort+0xb
> 0012f7cc 77e8c896 0012f7f4 00000000 0002021e
> NTDLL!CsrClientCallServer+0x92
> 0012f8b4 77e8c91d 00000007 0012f954 00000021
> KERNEL32!WriteConsoleInternal+0xd3
> 0012f8d0 77e68aee 00000007 0012f954 00000021
> KERNEL32!WriteConsoleA+0x16
> 0012f92c 1000f513 00000007 0012f954 00000021 KERNEL32!WriteFile+0x80
> 0012fd68 1000f399 00000001 00334010 0000001f 0x1000f513
> 0012fd80 1000e41c 00000001 00334010 0000001f 0x1000f399
> 0012fda0 1000acde 10017038 00000028 0012f8b4 0x1000e41c
> 0012fdbc 10006dce 00000001 10017038 00000028 0x1000acde
> 0012fde4 10001e82 10013560 00000000 00332828 0x10006dce
> 0012fe10 10001820 00332782 7ffdf000 00332780 0x10001e82
> 0012fe24 004023e8 00332782 00000000 004400d0 0x10001820
> 0012fe38 00401b28 0000002d 00000000 0012fe78 explorer!c_szHotkeys+0x178
> 0012ff80 004068e3 00000001 00351100 00351128 explorer!string'+0xc<br>&gt; 0012ffc0 77e7afff 00000028 0012f8b4 7ffdf000 explorer!string’+0xf
> 0012fff0 00000000 0040682f 00000000 0000018a
> KERNEL32!BaseProcessStart+0x3d
>
>
> FAILED_INSTRUCTION_ADDRESS:
> VINIC+44aa
> ed0644aa ?? ???
>
> FOLLOWUP_IP:
> VINIC+44aa
> ed0644aa ?? ???
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: VINIC+44aa
>
> MODULE_NAME:
>
> IMAGE_NAME: VINIC.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3d84d615
>
> STACK_COMMAND: kb
>
> BUCKET_ID: 0xD1_BAD_IP_VINIC+44aa
>
> Followup: MachineOwner
> ---------
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to %%email.unsub%%

4

thanx … thanx for that…

  1. FastIoctl => yes … i guess it has less overheads compared to
    convention Ioctls… my library frequently needs to send Ioctl to my
    driver… & moreover just some small structures. moreover i even thought it
    was easy to use… but if that’s creating problem… i’ll better rethink
    over it…

2.Interrupt object… In driver-initialisation, i register DPC followed by
Ioconnect interrupt … i don’t touch the interrupt object after that… do
i need to do anything more??

3.Regarding my ISR… that’s a question in my mind since long back… “if i
donot specify anything… is my driver code & hence the ISR & DPC pageable
or Loacked in memory???”

4.Do i explicitly need to specify my ISR & DPC as nonpageable??? if yes
how??

===> Regarding map file… really donno how to create it. ya but 'll try to
make it… symbols…(.pdb???) i’ve loaded it into WINNT\Symbols\sys.

In case i’am missing out anything please let me know…

Thanx, once again,

SP.

5

…& i’ve put the .map file below… in case u wish to refer to it.
============================================>

ccp3k

Timestamp is 3d7e07a2 (Tue Sep 10 20:24:26 2002)

Preferred load address is 00010000

Start Length Name Class
0001:00000000 00005422H .text CODE
0002:00000000 000000b4H .idata$5 DATA
0002:000000b8 00000094H .rdata DATA
0003:00000000 000040c8H .data DATA
0003:000040c8 0000004cH .bss DATA
0004:00000000 0000006aH INIT CODE
0004:0000006c 00000028H .idata$2 CODE
0004:00000094 00000014H .idata$3 CODE
0004:000000a8 000000b4H .idata$4 CODE
0004:0000015c 000003b4H .idata$6 CODE

Address Publics by Value Rva+Base Lib:Object

0001:00000175 _VipkDetach@4 00010415 f ccp3k_pci.obj
0001:000002c8 _VipkAddDevice@8 00010568 f ccp3k_pci.obj
0001:00000687 _VipkPnpDispatch@8 00010927 f ccp3k_pci.obj
0001:0000103f _VipkInitHardware@4 000112df f ccp3k_dev.obj
0001:00001429 _VipkUninitHardware@4 000116c9 f ccp3k_dev.obj
0001:00001803 _VipkHandleIoctls@28 00011aa3 f ccp3k_dev.obj
0001:00001d73 _VipkOpenNic@8 00012013 f ccp3k_dev.obj
0001:00001f9a _VipkCloseNic@4 0001223a f ccp3k_dev.obj
0001:000045f4 _VipkIntrHandler@8 00014894 f ccp3k_dev.obj
0001:0000467d _VipkDPCForIsr@16 0001491d f ccp3k_dev.obj
0001:00005416 _DbgPrint 000156b6 f
ntoskrnl:ntoskrnl.exe
0001:0000541c __except_handler3 000156bc f
ntoskrnl:ntoskrnl.exe
0002:00000000 xxxxx@KfAcquireSpinLock@4 000156e0 hal:HAL.dll
0002:00000004 xxxxx@KfReleaseSpinLock@8 000156e4 hal:HAL.dll
0002:00000008 \177HAL_NULL_THUNK_DATA 000156e8 hal:HAL.dll
0002:0000000c __imp__IoAttachDeviceToDeviceStack@8 000156ec
ntoskrnl:ntoskrnl.exe
0002:00000010 __imp__IoCreateSymbolicLink@8 000156f0
ntoskrnl:ntoskrnl.exe
0002:00000014 __imp__IoCreateDevice@28 000156f4
ntoskrnl:ntoskrnl.exe
0002:00000018 __imp__KeWaitForSingleObject@20 000156f8
ntoskrnl:ntoskrnl.exe
0002:0000001c __imp__RtlAssert@16 000156fc
ntoskrnl:ntoskrnl.exe
0002:00000020 __imp__KeInitializeEvent@12 00015700
ntoskrnl:ntoskrnl.exe
0002:00000024 __imp__IoConnectInterrupt@44 00015704
ntoskrnl:ntoskrnl.exe
0002:00000028 __imp__KeInitializeDpc@12 00015708
ntoskrnl:ntoskrnl.exe
0002:0000002c __imp__MmLockPagableSectionByHandle@4 0001570c
ntoskrnl:ntoskrnl.exe
0002:00000030 __imp__MmLockPagableDataSection@4 00015710
ntoskrnl:ntoskrnl.exe
0002:00000034 __imp__MmMapIoSpace@16 00015714
ntoskrnl:ntoskrnl.exe
0002:00000038 __imp__KeSetEvent@12 00015718
ntoskrnl:ntoskrnl.exe
0002:0000003c xxxxx@IofCallDriver@8 0001571c
ntoskrnl:ntoskrnl.exe
0002:00000040 __imp__IoDeleteDevice@4 00015720
ntoskrnl:ntoskrnl.exe
0002:00000044 __imp__IoDetachDevice@4 00015724
ntoskrnl:ntoskrnl.exe
0002:00000048 __imp__IoDeleteSymbolicLink@4 00015728
ntoskrnl:ntoskrnl.exe
0002:0000004c __imp__MmUnmapIoSpace@8 0001572c
ntoskrnl:ntoskrnl.exe
0002:00000050 __imp__MmUnlockPagableImageSection@4 00015730
ntoskrnl:ntoskrnl.exe
0002:00000054 xxxxx@IofCompleteRequest@8 00015734
ntoskrnl:ntoskrnl.exe
0002:00000058 __imp__RtlInitUnicodeString@8 00015738
ntoskrnl:ntoskrnl.exe
0002:0000005c __imp__RtlIntegerToUnicodeString@12 0001573c
ntoskrnl:ntoskrnl.exe
0002:00000060 __imp__RtlCopyUnicodeString@8 00015740
ntoskrnl:ntoskrnl.exe
0002:00000064 __imp__MmGetPhysicalAddress@4 00015744
ntoskrnl:ntoskrnl.exe
0002:00000068 __imp__KeInitializeSpinLock@4 00015748
ntoskrnl:ntoskrnl.exe
0002:0000006c __imp__ExAllocatePoolWithTag@12 0001574c
ntoskrnl:ntoskrnl.exe
0002:00000070 __imp__KeDelayExecutionThread@12 00015750
ntoskrnl:ntoskrnl.exe
0002:00000074 __imp__ExFreePool@4 00015754
ntoskrnl:ntoskrnl.exe
0002:00000078 __imp__WRITE_REGISTER_ULONG@8 00015758
ntoskrnl:ntoskrnl.exe
0002:0000007c __imp__MmProbeAndLockPages@12 0001575c
ntoskrnl:ntoskrnl.exe
0002:00000080 __imp__MmCreateMdl@12 00015760
ntoskrnl:ntoskrnl.exe
0002:00000084 __imp___except_handler3 00015764
ntoskrnl:ntoskrnl.exe
0002:00000088 __imp__MmUnlockPages@4 00015768
ntoskrnl:ntoskrnl.exe
0002:0000008c __imp__KeInsertQueueDpc@12 0001576c
ntoskrnl:ntoskrnl.exe
0002:00000090 __imp__IoFreeMdl@4 00015770
ntoskrnl:ntoskrnl.exe
0002:00000094 __imp__MmMapLockedPagesSpecifyCache@24 00015774
ntoskrnl:ntoskrnl.exe
0002:00000098 __imp__IoAllocateMdl@20 00015778
ntoskrnl:ntoskrnl.exe
0002:0000009c __imp__MmMapLockedPages@8 0001577c
ntoskrnl:ntoskrnl.exe
0002:000000a0 __imp__MmBuildMdlForNonPagedPool@4 00015780
ntoskrnl:ntoskrnl.exe
0002:000000a4 __imp__IoDisconnectInterrupt@4 00015784
ntoskrnl:ntoskrnl.exe
0002:000000a8 __imp__DbgPrint 00015788
ntoskrnl:ntoskrnl.exe
0002:000000ac __imp__RtlAppendUnicodeStringToString@8 0001578c
ntoskrnl:ntoskrnl.exe
0002:000000b0 \177ntoskrnl_NULL_THUNK_DATA 00015790
ntoskrnl:ntoskrnl.exe
0002:00000114 _microcode_version 000157f4 ccp3k_dev.obj
0003:00000070 _PCMicroCode 000158b0 ccp3k_dev.obj
0003:000037c0 _JumpVectorTable 00019000 ccp3k_dev.obj
0003:000038c8 _RxMicroCode 00019108 ccp3k_dev.obj
0003:00004110 _lockHandle 00019950
0004:0000001c _DriverEntry@8 0001997c f ccp3k.obj
0004:0000006c IMPORT_DESCRIPTOR_ntoskrnl 000199cc
ntoskrnl:ntoskrnl.exe
0004:00000080 IMPORT_DESCRIPTOR_HAL 000199e0 hal:HAL.dll
0004:00000094 __NULL_IMPORT_DESCRIPTOR 000199f4
ntoskrnl:ntoskrnl.exe

entry point at 0004:0000001c

Static symbols

0001:0000224e _VipkRegisterMem@20 000124ee f ccp3k_dev.obj
0001:000023b8 _VipkDeregisterMem@12 00012658 f ccp3k_dev.obj
0001:0000247f _VipkGetTpt@8 0001271f f ccp3k_dev.obj
0001:0000260e _VipkReleaseTpt@12 000128ae f ccp3k_dev.obj
0001:0000281c _VipkMapAndLock@12 00012abc f ccp3k_dev.obj
0001:00002961 _VipkUnmapAndUnlock@8 00012c01 f ccp3k_dev.obj
0001:00002aca _VipkWaitVi@24 00012d6a f ccp3k_dev.obj
0001:00002daf _VipkCreateCQ@20 0001304f f ccp3k_dev.obj
0001:00002f10 _VipkDestroyCQ@8 000131b0 f ccp3k_dev.obj
0001:00003172 _VipkWaitCQ@20 00013412 f ccp3k_dev.obj
0001:00003455 _VipkResizeCQ@20 000136f5 f ccp3k_dev.obj
0001:00003535 _VipkGetFreeBit@8 000137d5 f ccp3k_dev.obj
0001:000035a0 _VipkMarkBit@12 00013840 f ccp3k_dev.obj
0001:000035ef _VipkQueryNic@8 0001388f f ccp3k_dev.obj
0001:000036dd _VipkSetMemAttributes@16 0001397d f ccp3k_dev.obj
0001:000037ae _VipkQueryMem@16 00013a4e f ccp3k_dev.obj
0001:00003841 _VipkCMRegister@4 00013ae1 f ccp3k_dev.obj
0001:000038ab _VipkCMWait@12 00013b4b f ccp3k_dev.obj
0001:000039d4 _VipkCMGet@8 00013c74 f ccp3k_dev.obj
0001:00003afa _VipkCMPut@8 00013d9a f ccp3k_dev.obj
0001:00003bdc _VipkPutMsg@8 00013e7c f ccp3k_dev.obj
0001:00003f13 _VipKBindVi@8 000141b3 f ccp3k_dev.obj
0001:000043cc _VipKUnBindVi@8 0001466c f ccp3k_dev.obj
0001:00004a74 _VipkReadIrq@4 00014d14 f ccp3k_dev.obj
0001:00005073 _VipKMapErrorPage@8 00015313 f ccp3k_dev.obj
0001:00005267 _VipKMapDoorBellPage@8 00015507 f ccp3k_dev.obj
0001:00005364 _VipkMailBox@12 00015604 f ccp3k_dev.obj
0001:000053a4 _VipkLoadPC@4 00015644 f ccp3k_dev.obj
0001:000053ca _VipkLoadJVT@4 0001566a f ccp3k_dev.obj
0001:000053f0 _VipkLoadRx@4 00015690 f ccp3k_dev.obj
0001:00000a82 _VipkSetUpResources@12 00010d22 f ccp3k_pci.obj
0001:00000d2e _VipkSyncCompletion@12 00010fce f ccp3k_pci.obj
0001:00000d6c _VipkCallDriver@8 0001100c f ccp3k_pci.obj
0001:00000dca _VipkUninitDev@8 0001106a f ccp3k_pci.obj
0001:00000ec8 _AppendNumToString@16 00011168 f ccp3k_pci.obj
0001:00000015 _VipkUnload@4 000102b5 f ccp3k.obj
0001:00000045 _VipkOpen@8 000102e5 f ccp3k.obj
0001:000000a4 _VipkClose@8 00010344 f ccp3k.obj
0001:000000de _VipkAddFuncDevice@8 0001037e f ccp3k.obj
0001:00000104 _VipkIoctl@8 000103a4 f ccp3k.obj
0001:0000012c _VipkFastIoCtl@36 000103cc f ccp3k.obj
0001:0000014e _VipkPnpDispatchIoctl@8 000103ee f ccp3k.obj

Thanx,

SP.

6

Though it doesn’t relate to your bugcheck, I have to point out something
here - which quite a few people don’t realize - with respect to the
FastIoDeviceControl path.
I/O does NOT buffer the user-buffers, even if the method of the IOCTL is
METHOD_BUFFERED in this path. So the input/output buffers you deal with
in FastIoDeviceControl are always raw user buffers and you need to
always protect access to them with a try-except().

Ravi

-----Original Message-----
From: Shailesh [mailto:xxxxx@hotmail.com]
Sent: Tuesday, September 10, 2002 7:25 AM
To: NT Developers Interest List
Subject: [ntdev] Re: *** Fatal System Error: 0x000000d1

thanx … thanx for that…

  1. FastIoctl => yes … i guess it has less overheads compared to
    convention Ioctls… my library frequently needs to send Ioctl to my
    driver… & moreover just some small structures. moreover i even thought
    it was easy to use… but if that’s creating problem… i’ll better
    rethink over it…

2.Interrupt object… In driver-initialisation, i register DPC followed
by Ioconnect interrupt … i don’t touch the interrupt object after
that… do i need to do anything more??

3.Regarding my ISR… that’s a question in my mind since long back… “if
i donot specify anything… is my driver code & hence the ISR & DPC
pageable or Loacked in memory???”

4.Do i explicitly need to specify my ISR & DPC as nonpageable??? if yes
how??

===> Regarding map file… really donno how to create it. ya but 'll try
to make it… symbols…(.pdb???) i’ve loaded it into WINNT\Symbols\sys.

In case i’am missing out anything please let me know…

Thanx, once again,

SP.

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%