BugCheck (Blue Screen) in nipalk.sys using gpib.

[IM-MDA]

We have a Windows 2000 system that recently upgraded it's GPIB driver to version 2.4 from version 2.1, soon thereafter we started getting  blue screen crashes (on the order of once a week on a system that is constantly in use - 24x7). The bugcheck error reported by windows was: "0x0000001e (0xc0000047, 0x8042dc0c, 0x00000003, 0x00000000). Microsoft Windows 2000 [v15.2195]." A WinDbg analysis of the resulting crashdump is included below which shows the error in nipalk.sys. The module gpibprtk is at the top of the call stack.

The system has a PCI-GPIB board and a NI PCI-232 16 port RS-232 board. The application software uses NI-VISA to communicate with the hardware. The following software versions are installed:

Name	Version	Description
NI-488.2 Software	2.40	Controller & Analyzer Software
Measurement & Automation Explorer	4.0.0.3010	Use Measurement & Automation Explorer to manage your National Instruments products and services
NI-USI	1.0.2	NI Universal Storage Interface
NI-PAL Software	1.10.0f0	NI-PAL Library for Windows
NI-Serial Software	1.8.0	RS-232 & RS-485 Driver Software
NI Spy	2.3.0.49152	Monitors National Instruments API calls
NI-VISA	3.4.1	Virtual Instrument Software Architecture
visa32.dll	3.4.0.49152	VISA Library
NIvisaic.exe	3.4.0.49152	VISA Interactive Control Utility
LabVIEW Run-Time	8.0	LabVIEW Run-Time Engine

I am guessing that this problem was introduced with the install of Version 2.40 of the GPIB driver since we did not see this particular bugcheck during 2 years of operations running version 2.1. Does anyone know at what version this may have been introduced? Is there any other work-around to avoid the problem? Any help would be appreciated.

thanks,
Dan

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

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000047, The exception code that was not handled
Arg2: 8042dc0c, The address that the exception occurred at
Arg3: 00000003, Parameter 0 of the exception
Arg4: 00000000, Parameter 1 of the exception

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


OVERLAPPED_MODULE:  ati2drad

EXCEPTION_CODE: (NTSTATUS) 0xc0000047 - An attempt was made to release a semaphore such that its maximum count would have been exceeded.

FAULTING_IP:
nt!KeReleaseSemaphore+38
8042dc0c 85db             test    ebx,ebx

EXCEPTION_PARAMETER1:  00000003

EXCEPTION_PARAMETER2:  00000000

DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR:  0x1E

LAST_CONTROL_TRANSFER:  from f74bd110 to 8042dc0c

TRAP_FRAME:  f5d4e51c -- (.trap fffffffff5d4e51c)
ESP EDITED! New esp=f5d4e8cc
ErrCode = 00000000
eax=00000000 ebx=00000001 ecx=00000000 edx=00000000 esi=8599ecc4 edi=00000002
eip=8042dc0c esp=f5d4e590 ebp=f5d4e8e0 iopl=0         nv up ei pl zr na po nc
cs=0000  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000246
nt!KeReleaseSemaphore+0x38:
8042dc0c 85db             test    ebx,ebx
Resetting default scope

STACK_TEXT: 
f5d4e8e0 f74bd110 8599ecc4 00000000 00000001 nt!KeReleaseSemaphore+0x38
WARNING: Stack unwind information not available. Following frames may be wrong.
f5d4e90c f5b985e6 ffffffff 00000000 f5b89d9d nipalk!tSyncAtomicI32::operator=+0x830
f68f9938 85cb6f00 00000008 00000000 80011347 gpibprtk+0x125e6
f5bac678 f5b9fe90 f5b9fe00 f5b9ff20 f5b9fde0 0x85cb6f00
f5b9fdb0 00000018 082444f6 56077401 602815ff gpibprtk+0x19e90


FOLLOWUP_IP:
nipalk!tSyncAtomicI32::operator=+830
f74bd110 c20400           ret     0x4

SYMBOL_STACK_INDEX:  1

FOLLOWUP_NAME:  MachineOwner

SYMBOL_NAME:  nipalk!tSyncAtomicI32::operator=+830

MODULE_NAME:  nipalk

IMAGE_NAME:  nipalk.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4333476d

STACK_COMMAND:  .trap fffffffff5d4e51c ; kb

FAILURE_BUCKET_ID:  0x1E_nipalk!tSyncAtomicI32::operator=+830

BUCKET_ID:  0x1E_nipalk!tSyncAtomicI32::operator=+830

[Ebele_Obijiofor]

Hi Dan,

Does the crash happen randomly, or does something specific happen to make it crash. Thanks!

Regards,

[IM-MDA]

Hi Ebele,

The crash seems to be random.

thanks,
Dan

[Ebele_Obijiofor]

Hi Dan,

When you upgraded NI-488.2, did you also upgrade any of the other NI software listed in the report? Also, in the GPIB code that you have, are you making calls to any other hardware? Is it possible to provide some information about what your code is doing? Thanks!

Regards,

Message Edited by _Belle on 08-29-2006 09:15 PM

[IM-MDA]

About 3 weeks before the GPIB upgrade, we upgraded NI-VISA from version 3.0.1 to 3.4.1, at the same time we upgrade NI-Serial from version 1.5 to 1.8.

Our application is multi-threaded and there may be calls to devices attached to the RS-232 board at the same time as GPIB devices. However, only 1 thread has access to the GPIB devices at any one time, so you can't have concurrent GPIB activity. Also note that there are 8 GPIB devices attached to the GPIB board and 10 RS-232 devices.

Is this enough information?

thanks,
Dan

[Ebele_Obijiofor]

Hi Dan,

Could you configure your machine to create a kernel dump file when it crashes, and upload the MEMORY.DMP file to our ftp site (ftp.ni.com/incoming). I'll also suggest upgrading to the latest version of NI-VISA from the link here. Thanks!

Regards,

[IM-MDA]

Ebele,

I have uploaded the crash dump file message_board.id=140_message.id=19060_MEMORY.DMP to the location requested. I believe it is a full memory dump but I don't have direct access to the system right now. This was used to generate the crash dump analysis in my original post. (I can provide more crash dumps if you wish.)

As for upgrading the software, we could do this, but since this is an operational system, we hesitate to make changes such as this without careful consideration. (Unplanned downtime would have expensive repercussions.) Do you have any reason to believe that this may solve the problem? Or do you just want us operating from the NI standard baseline?

thanks for the help,
Dan

[Ebele_Obijiofor]

Hi Dan,

Could you send a spy capture doing fail safe logging to a file? This might really slow your application down, but it's worth a try, and will be helpful if you can. Thanks!

Regards,