LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

OmniDriver .NET interface - Error 1172 at NETWrapper() Constructor (System.Runtime.InteropServices.SEHException)

A customer of mine is trying to use one of Ocean Optics's spectrometers in LabVIEW, using the .NET interface for OmniDriver.

 

However, the customer is seeing error 1172 in LabVIEW which corresponds to an exception occurring in the .NET assembly.
The exception occurring is "System.Runtime.InteropServices.SEHException".
This exception is being thrown when running the constructor for NETWrapper, "NETWrapper()".

 

This is somewhat strange, because apparently this did not happen in the past, but started happening after they re-installed OmniDriver.

 

I've had the customer try various troubleshooting steps, such as the ones in the link below.
http://forums.ni.com/t5/LabVIEW/Ocean-Optics-Spectrometers-under-LabView-Ocean-Optics-OmniDriver/m-p...
I'm currently having the customer try out moving the VI/project to the same directory as or the directory above the NET assembly "NETOmniDriver-NET40.dll"
I tried getting the customer to register the assembly to the Global Assembly Cache (GAC), but they don't have gacutil.exe to be able to do that.
Trust doesn't seem to be an issue, because the assembly is loaded from the local disk, meaning that it should be fully trusted to begin with.

 


Any ideas about what could cause "System.Runtime.InteropServices.SEHException" in OmniDriver?
Are there any other troubleshooting steps I should have my customer do?

 

Thanks in advance.

 

P.S. I've already contacted Ocean Optics through their online form below, but I haven't been able to get a response yet...

http://oceanoptics.com/contact-us/

0 Kudos
Message 1 of 3
(3,845 Views)

@KaruKaru wrote:

A customer of mine is trying to use one of Ocean Optics's spectrometers in LabVIEW, using the .NET interface for OmniDriver.

 

However, the customer is seeing error 1172 in LabVIEW which corresponds to an exception occurring in the .NET assembly.
The exception occurring is "System.Runtime.InteropServices.SEHException".
This exception is being thrown when running the constructor for NETWrapper, "NETWrapper()".

 

This is somewhat strange, because apparently this did not happen in the past, but started happening after they re-installed OmniDriver.

 

I've had the customer try various troubleshooting steps, such as the ones in the link below.
http://forums.ni.com/t5/LabVIEW/Ocean-Optics-Spectrometers-under-LabView-Ocean-Optics-OmniDriver/m-p...
I'm currently having the customer try out moving the VI/project to the same directory as or the directory above the NET assembly "NETOmniDriver-NET40.dll"
I tried getting the customer to register the assembly to the Global Assembly Cache (GAC), but they don't have gacutil.exe to be able to do that.
Trust doesn't seem to be an issue, because the assembly is loaded from the local disk, meaning that it should be fully trusted to begin with.

 


Any ideas about what could cause "System.Runtime.InteropServices.SEHException" in OmniDriver?
Are there any other troubleshooting steps I should have my customer do?

 

Thanks in advance.

 

P.S. I've already contacted Ocean Optics through their online form below, but I haven't been able to get a response yet...

http://oceanoptics.com/contact-us/


You can just copy the assembly to the GAC using explorer if necessary (C:\Windows\assembly) if that helps. But I'm not conveniced that is the issue - LabVIEW is pretty clear if it can't find the assembly (or a dependent managed assembly) and error code 1172 is reserved for exceptions only, not fusion-related loading errors. Things I would try:

  • Based on the exception it is likely that the assembly is dependent on another unmanaged dll(s). You can use DependencyWalker to find out exactly what the assembly is dependent on and whether those files exist on disk (System32 or other).
  • You can de-compile the .NET wrapper using dotPeek or similar to see where the exception could be coming from. If the assembly came with a pdb file then you could debug the assembly in Visual Studio to see the call stack.
  • Try creating a simple console app in Visual Stuio using the same assembly and see what happens there (will also allow you to better debug).
0 Kudos
Message 2 of 3
(3,839 Views)

Hi 

I have the same issue. 
Did you fix it? How?

Thanks

0 Kudos
Message 3 of 3
(2,773 Views)