Use of Call Function Node vi, with char type pointer

[safe]

Hi intvsteve,

Here is the function from the dll:

__declspec(dllexport)
void npm_bb_read_register(unsigned char *bL, unsigned char *bH, unsigned int len, unsigned int adr)
{
 unsigned char  b[4] ;//= bL +  *bH * 0xffff;
 //DWORD start; 
 
 EnterCriticalSection(&cs);
 if (((len == 1) || (len == 4)) && (b != NULL) && already_init) {
  //nm_read_reg(adr, b, len);
  dbg(_ERR_, "..(%d)\n", (int)GetTickCount());
  pbus->nmi_bus_read((void *)&bustype, adr, (unsigned char *)b, len);
  dbg(_ERR_, "..(%d)\n", (int)GetTickCount());

  dbg(_ERR_, "read reg: (%d)(%08x)(%08x)\n", len, adr, *((DWORD*)b));
 }
 *bL    = b[0];
    *(bL+1)= b[1];
 *(bH)  = b[2];
 *(bH+1)= b[3];

  
 LeaveCriticalSection(&cs);
}

[safe]

Hi Intvsteve,

Sorry, I had given wrong function header.  But to me it makes no sense how come there is an error on the dll.  The only thing I could think of, is that the NM312DLL is calling other dlls internally.  I don't think that should cause a problem for LabVIEW  it should be ok right?

Thanks,

Safe

[intvsteve]

Have you had a chance to look in the debugger to pinpoint where you're hitting the exception?

For example, if the exception is raised in pbus->nmi_bus_read((void *)&bustype, adr, (unsigned char *)b, len); then the trouble's there.

Also, what is the value of 'len' you're passing vs. the size of the byte arrays for bL and bH? For example, if 'len' is one, depending on what you've passed to the function, you may crash simply because of:

*(bL+1)= b[1];

 or

*(bH+1)= b[3];

Curious why the code's using the somewhat obfuscated *(bL+1) vs. bL[1] for assignment, but that's not really important.

As to calling conventions... My hunch is that the function is stdcall. Not 100% sure on this, but I think that's the default mechanism for Visual Studio (assuming that's the compiler you're using).

[safe]

Thanx for the advice...I will explore more options and seriously think with the advices you have given me

[safe]

Hi Intvsteve,

I have proven that function paramater naming is not a problem.  I have another DLL that works with 1 unsigned integer pointer, rather than the char pointer.  unfortunatly i still get 1097 error.  Here are the two functions:

void npm_bb_read_register(unsigned int *b, unsigned int len, unsigned int adr)

void npm_bb_write_register(unsigned char *bL, unsigned char *bH, unsigned int len, unsigned int adr)

What do you suggest is the problem?  I did tried both threads, but i don't know anything about the memory overwritten, or how I can stop that problem.

Thanx,

Saif

[intvsteve]

At this point, the only recourse you have is to run your DLL in a debugger, with a debug version of the DLL it, in turn, is calling. That way you should be able to see who's throwing the exception, and why. The error you're seeing is the result of something down the call chain of the function you're calling from LV, and whatever that thing is, it's throwing an exception -- and nobody caught it until it got back into LabVIEW. There are many reasons this can happen. The most common ones have been discussed here, such as calling conventions, improperly configured parameter lists or data types, or threading issues. With the information we've got, no obvious problems exist on the VI side of things.

The error '1097' results from *someone* throwing an exception, and LabVIEW caught it. The pseudo-code for the call library node is something like this...

void ExecuteCallLibraryNode()

{

try

{

 CallTheFunctionDefinedInCallLibraryNode(with_the_arguments_from_the_diagram);

}

catch(...)

{

 // Uh oh. Something in the function the user told us to call threw an exception, and nobody caught it.

 // Instead of crashing LabVIEW, we'll warn the user that this happened to give them a chance to quit.

 // *HOPEFULLY* memory didn't get too corrupted, and the user can save what needs saving without losing it...

 ReportErrorMessage(error1097);

}

}

The purpose of error 1097 is specifically to report when a crash of some sort happened during the execution of code that LV has no control over. It could be many things... But at this point, I don't see anything at 'the LabVIEW' end... you'll really need to check this with a debugger.