More information regarding paths

[AndyWatt]

The UK is in the office for three days starting today before "wedding mania" knocks everything offline again.

Ray and Dug - I'll get babck to you with more information. Some good tips there - I will check to see what I can get through use of microsoft symbols (note, I am debugging using VS2005's IDE debugger: I will dig to see if I need to make any settings changes to ensure it uses microsoft symbols for any loaded DLLs) - I've done debugging work in WinDbg with automatically downloaded symbols from the microsoft server before.

One thing: if TestStand isn't doing anything elaborate, then Windows must be: see the TestStand debugger output text file in the original post where the WinTseInterface DLL is reported as loaded twice, second time (managed). This leads me back to something I was considering last week: some changes I made in the SerialSessionMgr DLL project to facilitate late-loading of the WinMM DLL (before mscoree.dll and the .Net subsystem) were put in to stop WinMM from bringing down the entire system (this is easily google-able) and I'm now wondering if the linkage to DelayImp.lib is causing some unforseen issues here.

It's a little like being a rat in a distinctly unfriendly maze, this, but I want to get to the bottom of it.

Cheers again for this help.

[AndyWatt]

Interesting - using WinDbg (another tool I'm learning to use more in-depth here) I've managed to get the system including TestStand to break when the exception happens (WinDbg calls this exception e06d7363 BTW, which I understand essentially means "C++ exception"), and I have a call stack, attached.

I think it gives more clues - does it appear that it can't find the managed assembly _inside_ the "IJW" DLL? Do you think it would help if I disabled JIT....?

Any more thoughts?

Andy

[AndyWatt]

Hi again anyone following this.

Some extensive testing today revealed that an empty string being passed into a CString parameter for the Initialise() call helped, amongst other things. I suspect I may have found another issuethough - I think the managed DLL-contained assemblies underneath the WinTseInterface DLL are only being searched for in the "bin" directory of the TestStand program files directory, where the executable is.

I say this as I've been debugging under WinDbg and managed to work out from a stack frame for the exception that the Interfaces assembly wasn't found. When I rebuilt everything to include my small fix for the empty string parameter, and moved all the relevant files to the TS BIN directory - here's my debug output:

TseStartSession Sepura

'SeqEdit.exe' (Managed): Loaded 'C:\workspaces\astt_fte_wrapper\fte_wrapper\astt\SerialSessionMgr\bin\WinTseInterface_D.dll', Symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\diasymreader.dll', No symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_5490cd9f\msvcm80d.dll', Symbols loaded.

'SeqEdit.exe': Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\Interfaces.dll', Symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\Interfaces.dll', Symbols loaded.

'SeqEdit.exe': Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\Logger_D.dll', Symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\Logger_D.dll', Symbols loaded.

'SeqEdit.exe': Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\DataDictionary_D.dll', Symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\DataDictionary_D.dll', Symbols loaded.

'SeqEdit.exe': Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\TSECommunicator_D.dll', Symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\TSECommunicator_D.dll', Symbols loaded.

'SeqEdit.exe': Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\Interpreter_D.dll', Symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\Interpreter_D.dll', Symbols loaded.

'SeqEdit.exe': Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\Filter_D.dll', Symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\Filter_D.dll', Symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Configuration\2fb45bb85014fd6e20222f95d9ada241\System.Configuration.ni.dll', No symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System.Configuration\2.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll', No symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Xml\93eb6a059bbc17168d0002d35736cad4\System.Xml.ni.dll', No symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System.Xml\2.0.0.0__b77a5c561934e089\System.Xml.dll', No symbols loaded.

C:\Program Files\National Instruments\TestStand 4.2.1\Bin\HighLevelMonitor_D.dll not found

If the highlighted files are not placed in the directory with Teststand, but instead are left with the other DLLs and the ".seq" file, then we see this output:

TseStartSession Sepura

'SeqEdit.exe' (Managed): Loaded 'C:\workspaces\astt_fte_wrapper\fte_wrapper\astt\SerialSessionMgr\bin\WinTseInterface_D.dll', Symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\diasymreader.dll', No symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_5490cd9f\msvcm80d.dll', Symbols loaded.

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: TEException at memory location 0x0e8cc0f8..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: TEException at memory location 0x0e8cdef4..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

'SeqEdit.exe': Loaded 'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\stdole\392cab30bfddf32acc48b719f39b7b77\stdole.ni.dll', Binary was not built with debug information.

'SeqEdit.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorsec.dll', No symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\system32\wintrust.dll', No symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\system32\crypt32.dll', No symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\system32\msasn1.dll', No symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\system32\imagehlp.dll', No symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\system32\userenv.dll', No symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\system32\cryptnet.dll', No symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\system32\sensapi.dll', No symbols loaded.

'SeqEdit.exe': Loaded 'C:\WINDOWS\system32\winhttp.dll', No symbols loaded.

'SeqEdit.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC\stdole\7.0.3300.0__b03f5f7f11d50a3a\stdole.dll', No symbols loaded.

'SeqEdit.exe': Loaded 'C:\Program Files\National Instruments\TestStand 4.2.1\Bin\ExprEdit.dll', No symbols loaded.

The thread 'Win32 Thread' (0x120c) has exited with code 0 (0x0).

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: TEException at memory location 0x001294b8..

First-chance exception at 0x7c812afb in SeqEdit.exe: Microsoft C++ exception: TEException at memory location 0x0012882c..

The thread 'Win32 Thread' (0x470) has exited with code 0 (0x0).

The thread 'Win32 Thread' (0x15ec) has exited with code 0 (0x0).

The thread 'Win32 Thread' (0x1068) has exited with code 0 (0x0).

[AndyWatt]

... and, I should add in addition to that last post, we receive Error 17501 instead.

I think at this stage we've got to the bottom of the original "crash" error which gave us the error 17502 (this turns out to be problems creating a temp MFC CString parameter using an empty "" literal, I think) - but one of my hypotheses has come to pass - TestStand does not appear to be able to realise that all the managed assemblies which are called from my mixed IJW WinTseInterface bridging DLL are in the same directory as the sequence file.

I think I may have some more items to work through in addition to this, but right now the paths issue is the one I need to resolve. Does the C/C++ adapter have an issue here?

[dug9000 · Accepted solution]

Hi Andy,

It sounds like you've had a lot of success in debugging things. That's wonderful.

---

@AndyWatt wrote:

... and, I should add in addition to that last post, we receive Error 17501 instead.

I think at this stage we've got to the bottom of the original "crash" error which gave us the error 17502 (this turns out to be problems creating a temp MFC CString parameter using an empty "" literal, I think) - but one of my hypotheses has come to pass - TestStand does not appear to be able to realise that all the managed assemblies which are called from my mixed IJW WinTseInterface bridging DLL are in the same directory as the sequence file.

I think I may have some more items to work through in addition to this, but right now the paths issue is the one I need to resolve. Does the C/C++ adapter have an issue here?

---

The behavior of finding assemblies in the exe's directory (Also known as the application base path) is a .NET behavior defined by Microsoft and has nothing to do with TestStand. There are workarounds and configuration files that can be used to alter this behavior, but it is how .NET works by default and not in any way defined by TestStand.

That said, if you loaded your assembly in TestStand using the .NET adapter rather than calling it from C, you would get behavior more like what you desire (i.e. finding dependent assemblies in the same directory as the one specified for the step). That is because the .NET adapter uses an alternate way of loading assemblies when loading them by path by using the .NET LoadFrom API. You mentioned you want this to be a C API though and called from other things besides TestStand, so this might not be a good solution for you. The problem you are having with TestStand you will also have with any other program which uses your dll if you don't put all of the dependent dlls in the exe's directory. Another alternative that you might prefer is to put your assemblies in the GAC (Global assembly cache) instead. Otherwise you will need to research other alternatives in Microsoft's documentation for .NET or elsewhere. You could perhaps call LoadFrom in your own stub dll to load your assembly in the LoadFrom context, or perhaps you can use appconfig files to alter the load behavior. There are many possibilities, but what you are wanting to do is not the way .NET works by default.

Here's some documentation by Microsoft to help get you started in researching how things work:

http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx

http://msdn.microsoft.com/en-us/library/dd153782.aspx

Hope this helps,

-Doug

[AndyWatt]

Hi again Doug,

That's excellent information!

"Great minds" - late yesterday evening I started tinkering with Assembly::LoadFrom() to look at manually loading the assemblies - at one stage I was trying this approach out for the original crash issue - this approach should cure the problem of loading the assemblies from the directory the WinTseInterface DLL "wrapper" is located in, thanks for that.

This issue has been a rollercoaster - I've done more in-depth debugging using WinDbg than I've ever done before, digging into managed and unmanaged stacks, setting breakpoints... I'd like to share some information with you guys too, if you don't already have it. WinDbg was incredibly useful once I got over 

I found a great resource on common  WinDbg commands - a useful reference  - here:

http://windbg.info/doc/1-common-cmds.html#top

there's some great information about how to set breakpoints - including how to dump the DllMain() reason calls. I worked out how to set breakpoints on the C++ EH exceptions from this, plus...

C++ exceptions (0xE06D7363) and how to decode exception object types

http://blogs.msdn.com/b/oldnewthing/archive/2010/07/30/10044061.aspx

Again, many thanks. I think this issue is now closed (although like I said before, I suspect I may have others coming up...)