Using third-party COM-Server via VC++-DLL in TestStand

[mbrost]

Hi,
I've written a DLL in VC++ that uses a third-party COM-Server. I also have a little test application which works just fine with that DLL.
The DLL incorporates a working thread for interaction with the COM-Server. Communication between main thread and working thread is being done by events.
Unfortunately TestStand isn't as cooperative as my test application. TestStand starts the COM-Server, and I can use it but when I try to close my DLL (ending all threads) and the COM-Server with a teststep Teststand crashes (exception by SeqEdit.exe). The COM-Server application is closed without any problems. Debugging my DLL doesn't get give any clue - everything works fine in the DLL. What am I doing wrong?

[Scott_Richardson]

To mbrost -
It sounds like the COM server application in an EXE and not a DLL. If an EXE server, it is unlikely that the COM EXE server is at fault here. Because your DLL is out of process from the COM EXE server, the OS uses RPC threads to do the marshaling of data between your DLL and the server. Sometimes these RPC threads are still active even though you are no longer going to access the server.

I have seen some cases where it is best to force your DLL to stay in memory by invoking one extra LoadLibrary on itself and to also leave the worker thread around until the process shutsdown.

Questions:
1) When does it crash? Does the call to the teststep that is shutting down your DLL crash, does TestStand crash after the step runs, when the executi
on completes, when TestStand shutsdown?
2) What stack trace do you have in MSVC when the crash occurs?
3) What type of exception occurs? And what does the debugger log look like at that point?
4) What is the name of the COM-server product?
5) Does your DLL and/or COM server require hardware or externals to run? Is it something that someone else can look at if necessary?

Scott Richardson (NI)

[mbrost]

Dear Mr.Richardson,
thank you for your answer.
Here are the answers to your questions (to the best of my knowledge):

Regarding 1: TestStand (the sequence editor) crashes after the step executed (It crashes after I leave the function of my DLL, that was called, via return) - I did some debbuging today and found a rather strange behavior: When the debugger stops and I go through execution step by step, everything works fine but if I stop and then resume execution it crashes. I think I leave the working thread and the DLL to quickly - if I put a Sleep command right after the command to close the COM EXE server and before I leave the working thread everything works fine. It seems windows tries to communicate with the DLL/thread after it closed the
COM EXE server - maybe some result reporting? I probably need to go into the details of COM and ActiveX.

Regarding 2: I've added a screenshot of the debugger when it chrashes the stack is in the lower left corner.
It seems OLE32 causes a problem - but I don't know what to do about it.

Regarding 3: I've added a screenshot of the debugger and its log when it chrashes.

Regarding 4: The application is called CANalyzer by the company Vector Informatik GmbH (Germany). It's a tool to handle a CAN-bus.

Regarding 5: The CANalyzer needs a CAN-Board to start a measurement (its coupled to the serial number of the board as a dongle). The application can be started without any hardware present though - only the actual measuring needs hardware. A valid board is present and works just fine.

Gruss
Michael Brost

[Scott_Richardson]

Michael -
Your thought on not waiting long enough is a typical problem. Looking at the screen shot of your code, it appears that you do not wait for the worker thread to exit. It might be a good idea to actually wait for the thread to exit and then return to TestStand.

Also, I suspect that you are having to CoInitialize the thread that calls the com server. Make sure that you UnCoInitialize before exiting the thread. If you do not do it, the OS will do it for you, but it is better for you to do it. If you could wait until the UnCoInitialize completes and the thread exits before returning to TestStand that might be the trick.

Scott Richardson (NI)