LabVIEW crashing, call library function

[Curt Corum]

Hello,

I am using LabVIEW "Call Library Function" to call functions from a DLL MCBCIO32.DL
to control an Ortec Trump PCI 2k Multi Channel Buffer card.

I am getting very erratic behavior, including numerous crashes of LabVIEW,
sporadic functionality (i.e. everything works) and spurious communications
with the hardware through the DLL function calls.

The calling conventions I'm using are:
StdCall (WIN API)
Pascal Strings
Run in UI

I have disabled multi-threading in the LabVIEW preferences.

I have checked and double checked the individual wrapped DLL calls for data
type etc,
and each have been tested with success.

I've gotten various combinations of the following:

LABVIEW caused an invalid page fault in
module
LABVIEW.EXE at 017f:007b30aa.
Registers:
EAX=0000005e CS=017f EIP=007b30aa EFLGS=00010217
EBX=00000000 SS=0187 ESP=00a7f0dc EBP=00a7f14c
ECX=01fb0000 DS=0187 ESI=01fb0000 FS=2b0f
EDX=e8240487 ES=0187 EDI=014f061c GS=0000
Bytes at CS:EIP:
66 8b 0a 66 3b cf 73 4e 66 3b c1 73 03 66 8b c1
Stack dump:
00a7f14c 014f21b8 00000000 00000608 01fb557a
01fb75f6 007b2fc1 00000000 014b0000 0000f11c
014b0da8 bff7b9c5 00000000 014b0000 014b0da8 014b0000

Error#3:"memory.c", line 793 (then CRASH)

Memory is full VI "Trump_test2.vi" was stopped
at node 0x1798 of SubVI "Trump_GetLastError.vi" (then CRASH)

"Insane Object" (then CRASH)

Is any of this behavior familiar, does anybody have suggestions.

Please Reply by e-mail as well as posting,

Thanks,

Curt

===============================

Curt Corum
Research Assistant
Radiology Research Labs
P.O. Box 245067
AHSC Bld. 211 Rm. 117
1609 N. Warren
Tucson AZ, 85724

(520) 626-9433
(520) 626-2892 fax
curt.corum@optics.arizona.edu

[Johnner]

Curt Corum wrote:

> I am using LabVIEW "Call Library Function" to call functions from a DLL MCBCIO32.DL
> to control an Ortec Trump PCI 2k Multi Channel Buffer card.
>
> I am getting very erratic behavior, including numerous crashes of LabVIEW,
> sporadic functionality (i.e. everything works) and spurious communications
> with the hardware through the DLL function calls.

Here are a couple of thoughts:

- First, one that is probably bogus, but perhaps worth trying because it's easy: run
Scandisk. I say this because one of the support guys here apparently got relief from
the "memory.c", line 793 failure after running Scandisk once upon a time. It certainly
could have been a coincidence.

- Second, take an even closer look at the DLLs that are getting called, paying
p
articular attention to those with array or string inputs. Page faults, exceptions,
and memory-related LabVIEW "failure" messages are a really good sign that memory
addresses are getting clobbered inside the DLLs. You'll get the failures if the wrong
LabVIEW memory addresses are getting overwritten, and you'll get the OS-level crashes
if memory associated with other applications (or the OS) is threatened.

Regards,
John Lum
National Instruments