Problems using a c++ dll in VB.net Compact Framework

[Joe]

Hi,

We used to use Pocket PC 2002 and embedded visual tools 3 for
development of applications and a driver dll. Recently we have been
required to bring our software up-to-date so developers can use it
with the .net compact framework.
Our driver dll previously used callback functionality, which is of
course not supported in .net, so we added functions which would take
the window handle of the application and pass back messages to it. We
also recompiled the dll in eVC++ 4, to be compatible with Pocket PC
2003.
To test this new functionality, we have written a VB.net application.
However, after seeming to work ok after a few function calls to the
dll, when going through the same process again, on the second or third
time through (usually depends on how fast you are executing, if not
stepping into code it will do it on the second run through, if
debugging then it can be 4th or 5th time!), the program will just
disappear, with no exception or any trace to explain why. Also it
doesn't do this disappearing act at the same dll function every time
either, as far as I can tell at least.

I am having a great deal of trouble tracing the cause of this, and am
wondering if anyone has experienced this as well, and/or has any tips
on how to proceed?

Thanks in advance of help,
Zief

 

[Alex Feinman [MVP]]

This usually means you have memory or stack corruption. You might have some
luck trying to debug it from the other end. See my article at
http://www.alexfeinman.com/articles/PInvoke-Debugging/PIDebug.htm

 

[Joe]

I had actually already discovered your debugging tool and tried it
out. Unfortunately, I can't get much closer to a solution using it, as
it drops out of debugging with the error "First chance exception in
CFLauncher.exe: 0x80000002: Datatype Misalignment, after a few uses of
the dll, but I am struggling to pinpoint where. I have looked into
this error and found it could be due to types in a structure being in
the wrong order or byte aligned incorrectly. I have made sure both the
dll and the application both define the structure in the same order,
and have tried all the byte alignment options, but still have the same
problem.

Anyone have any more ideas?

Joe

 

[Chris Tacke, eMVP]

Post the definition for the struct. My bet is it's not WORD aligned.

--
<ctacke/>
www.opennetcf.org/sdf
Winner of the 2004 Pocket PC Magazine Best Software award

 

[Joe]

The eVC++ dll struct is defined as

typedef struct TagInfoTypeTag {
UInt16 FirmwareVersionBCD;
UInt16 TagSize;
UInt8 PageWriteMaxSize;
bool PasswordSetFlag;
bool PasswordEnteredFlag;
bool MemoryLockSetFlag;
UInt16 MemoryLockAddress;
UInt32 SerialNumber;
UInt8 BaudRateAdjust;
}TagInfoType;

and the byte alignment is set to 8 bytes default.

In the vb.net app, the struct is recreated in the form:

<StructLayout(LayoutKind.Sequential)> _
Public Structure TagInfo 'Tag information staructure definition
Public FirmwareVersionBCD As UInt16
Public TagSize As UInt16
Public PageWriteMaxSize As System.Byte 'UInt8
Public PasswordSetFlag As System.Byte 'Boolean
Public PasswordEnteredFlag As System.Byte 'Boolean
Public MemoryLockSetFlag As System.Byte 'Boolean
Public MemoryLockAddress As UInt16
Public SerialNumber As UInt32
Public BaudRateAdjust As System.Byte 'UInt8
End Structure

Does this help?

Cheers,
Joe

 

[Chris Tacke, eMVP]

A C++ bool is not a System.Byte. By using it that way, you're getting a
read misalignment, which on ARM causes an abort.

IIRC
bool = 2 bytes
BOOL = 4 bytes

 

[Zief]

I tried changing this, but the behaviour is still the same.

I checked in eVC++ 4 help and bool is in fact only 1 byte, so I am not sure
that is the problem. vb.net booleans are either 2 or 4 bytes according to
the help, so I have changed it back to the byte.

Any more ideas?

It seems like it is just being unstable because it is calling functions in a
dll wrote in c++, but I'm sure there would have been more messages about
this if .net was that bad when calling dll functions.

Joe