DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) Probably caused by : nimdsk.dll

[Don Walker - Honeywell]

Working on a driver for a custom test equipment solution. This error consistently pops up. If you look at the stack trace, it appears like it happens when nipalk interrupts my dispatch routine. I'm looking into if I am causing this somehow. It would be nice if someone could tell me whether the ni driver is actually trying to access paged memory from the interrupt or if this bugcheck is because the memory pointer is actually corrupted.  I can provide the kernel memory dump. Let me know how best to proceed. Thanks.

Don Walker

Honeywell

913-712-2193

don.walker@honeywell.com

*** Fatal System Error: 0x000000d1
                       (0xE13C71C8,0x0000001C,0x00000000,0xF2D71F69)

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.

Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
..................................................................................................................................................
Loading User Symbols
..................................................................
Loading unloaded module list
..........
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {e13c71c8, 1c, 0, f2d71f69}

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for nimdsk.dll -
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for Nidaq32k.SYS -
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for nipalk.sys -
Probably caused by : nimdsk.dll ( nimdsk!NIMDS100::tMDSPrimitive::_markAllAttributesChanged+2a9 )

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

nt!RtlpBreakWithStatusInstruction:
80455554 cc              int     3
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: e13c71c8, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f2d71f69, address which referenced memory

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

READ_ADDRESS:  e13c71c8 Paged pool

CURRENT_IRQL:  1c

FAULTING_IP:
nimdsk!NIMDS100::tMDSPrimitive::_markAllAttributesChanged+2a9
f2d71f69 393c98          cmp     dword ptr [eax+ebx*4],edi

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  Debugger.exe

TRAP_FRAME:  eb423d7c -- (.trap ffffffffeb423d7c)
ErrCode = 00000000
eax=e13c71c8 ebx=00000000 ecx=0000002f edx=00000000 esi=f16e6cb0 edi=00000115
eip=f2d71f69 esp=eb423df0 ebp=eb423e48 iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
nimdsk!NIMDS100::tMDSPrimitive::_markAllAttributesChanged+0x2a9:
f2d71f69 393c98          cmp     dword ptr [eax+ebx*4],edi ds:0023:e13c71c8=000000d2
Resetting default scope

LAST_CONTROL_TRANSFER:  from 8042a9e7 to 80455554

STACK_TEXT: 
eb4239a4 8042a9e7 00000003 eb4239ec e13c71c8 nt!RtlpBreakWithStatusInstruction
eb4239d4 8042afda 00000003 e13c71c8 f2d71f69 nt!KiBugCheckDebugBreak+0x31
eb423d60 80467df7 00000000 e13c71c8 0000001c nt!KeBugCheckEx+0x390
eb423d60 f2d71f69 00000000 e13c71c8 0000001c nt!KiTrap0E+0x20b
WARNING: Stack unwind information not available. Following frames may be wrong.
eb423e48 f244d7c0 00000000 f88c3550 f88c4c00 nimdsk!NIMDS100::tMDSPrimitive::_markAllAttributesChanged+0x2a9
eb423e70 bfec9627 80030000 bfeea7e4 f88c34d8 Nidaq32k!mdsSCXICommDigPrimitive::shiftOneByte+0x3cc00
eb423e8c bfeeb18e 8179b008 f88c34d8 8209a00c nipalk!tBusFlavorSimulated::tBusFlavorSimulated+0xc7
eb423ea4 bfeeb3f9 8209a00c bff0c067 8179b008 nipalk!tInterruptGroup::_serviceHardwareInterrupt+0xce
eb423ec0 bfeeab57 eb423edc f88c07c0 eb423ee8 nipalk!tInterruptGroup::_setLockState+0xb9
eb423ed0 bff0bf6c eb423edc bff25760 00000000 nipalk!tInterruptGroup::runAtomicOperation+0x47
eb423ee8 80468a80 8179b008 f88c34d8 00000012 nipalk!tTimerTimeWasterSleep::sleep+0x304c
eb423f00 80468a48 02000002 00000039 8041e152 nt!KiChainedDispatch2ndLvl+0x28
eb423f00 8042b715 02000002 00000039 8041e152 nt!KiChainedDispatch+0x28
eb423f90 804354ba 81fce164 00000000 00000000 nt!KeSetEvent+0x33
eb423fa0 f8821c92 81fce164 00000000 00000000 nt!VerifierSetEvent+0x34
eb423fb4 f882e78e 81fce140 81fce0d0 00000001 RT429SIM!WriteQueueHasData+0x22 [d:\winddk\3790.1830\src\rt429sim\filethread.c @ 311]
eb423fc8 f882168d 81fd7068 00000000 81fce0d0 RT429SIM!MaintainADLPTimersFiles+0x8e [d:\winddk\3790.1830\src\rt429sim\adlp_718.c @ 1953]
eb423fe0 804644c7 81fce08c 81fce018 00000000 RT429SIM!DpcForIsr+0xad [d:\winddk\3790.1830\src\rt429sim\isrfunc.c @ 283]
eb423ff4 80468eaa f2bb0ce0 00000000 00000000 nt!KiRetireDpcList+0x30
eb423ff8 f2bb0ce0 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2a
80468eaa 00000000 00000008 bb835275 00000128 0xf2bb0ce0

STACK_COMMAND:  kb

FOLLOWUP_IP:
nimdsk!NIMDS100::tMDSPrimitive::_markAllAttributesChanged+2a9
f2d71f69 393c98          cmp     dword ptr [eax+ebx*4],edi

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  nimdsk!NIMDS100::tMDSPrimitive::_markAllAttributesChanged+2a9

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nimdsk

IMAGE_NAME:  nimdsk.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  3ce40f83

FAILURE_BUCKET_ID:  0xD1_VRF_nimdsk!NIMDS100::tMDSPrimitive::_markAllAttributesChanged+2a9

BUCKET_ID:  0xD1_VRF_nimdsk!NIMDS100::tMDSPrimitive::_markAllAttributesChanged+2a9

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

[MickeyD]

Don,

I will look at this issue and see what we can learn here, but applications engineers are not trained typically in driver development.  I would recommend posting this in the driver development forum at this link.

http://forums.ni.com/ni/board?board.id=90

The users of the forum are far more experienced in this kind of development, but I will get back to you with any information I find.

Have a great day,

Michael Denton
Applications Engineering
National Instruments

[Don Walker - Honeywell]

OK. I reposted the question over in the DDK forum. Thanks.

[MickeyD]

Hi Don,

I think your difficulty is related to the fact that you have the same IRQ for two cards on your system.  I was wondering if there was a reason you had your cards on the same IRQ.  I have asked some DAQ driver developers about what traditional DAQ would do if the IRQ was being used by two PCI cards.  I will get back to you with what I find out, but please let me know if having the same IRQ is required for your situation so I can make sure that R&D knows this as well.

Have a great day,

Michael D
Applications Engineering
National Instruments

[Don Walker - Honeywell]

It looks like our corporate system policy is preventing me from changing hardware resources for the card. I've entered a ticket to get that fixed. It may be a few days before that gets rectified. I'll post again with the results once I can change them.

[Don Walker - Honeywell]

OK. I looked into this IRQ resources thing a little more. The reason I can't change the resources are in this MSDN article.

http://search.support.microsoft.com/kb/252420/

Have you encountered this before? How do you propose I work around this issue?

I have also continued looking into my own driver. Even with everything commented out except for reads and writes to my card, the crash still happens. I know these reads and writes are correct because I can see the bus traffic on my card externally. Additonally, when I run the same test on a newer motherboard with more interrupts, the crash does not happen.

This indicates to me that it is the mere existence of my driver on the same IRQ causing the crash, not that it is actually doing anything to the NI driver specifically. Please let me know how best to work through this issue with NI. Thank you.

[MickeyD]

Hey Don,

I am looking into this.  I just want to make sure that your other card is a PCI card right.  It is not an ISA board?  What IRQ options do you have in your system BIOS?  Do you know if this board has been able to run with any other PCI boards?  I think that would be a way to see how the driver is working.  I know we can have any number of PCI boards running on a single IRQ, but I have not tested this with the board you are using obviously.  I could see if we have a simialar board around.  Get back to me with that information and I will get back to you with what I find about our drivers dealing with board sharing IRQs.

Have a great day,

Michael D
Applications Engineering
National Instruments

[Don Walker - Honeywell]

The card I am using is a Condor Engineering CEI-520, recently acquired by GE. ( http://www.gefanucembedded.com/products/1025 )  It is a 16 channel digital serial card for testing avionics. This particular model is a PCI board. The card comes with a driver and DLL that you can program from user mode to do most things. However, for our particular application, I needed to hook interrupts. So I worked with Condor to write a driver to do that under WIN98. That driver has been functioning for 4 or 5 years now. This version I am working on now runs on Win2K and is completely redesigned. It has been running smoothly for about a year. This error only happens when we run a test that really taxes the system. We've got 3 channels of the PCI 6602 DMAing stuff while my card is busily servicing interrupts as well. We have previously ran this test successfully under WIN98 on this very machine. So my suspicion is that there is a synchronization issue in the WIN2K driver for the 6602 that gets uncovered by this scenario. Like I said in my original post, I have a Kernal Dump I can provide to the NI developer if they want to look into it. They can load that into windbg and see what led up to the crash. I can't really learn anything from it because I don't have the driver source for the 6602. If I had that and a symbol file, I could probably debug it myself. 

I have an identical system that I am going to run this test on today for comparison.

[Don Walker - Honeywell]

OK. Because I had been debugging this issue, I have been running with a bunch of things that affect performance. So as an experiment, I compiled the driver in free mode, ran windows in normal mode, and turned off the driver verifier. No more bugchecks. I still had a small issue in the app code where a buffer was getting overrun, but I scheduled the task to run faster and took care of that. So running everything in debug mode was slowing the performance down to the point that it was stressing the NI driver past operating. Still, it should not bugcheck. It should fail more gracefully than that. If you want my help finding the bug, I can reproduce it pretty easily and send the kernel dumps.

Don Walker

Honeywell

913-712-2193