cancel
Showing results for 
Search instead for 
Did you mean: 

Start of custom DLL fails randomly

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom

We recently see problems with starting our and a customer's custom DLLs in NX 10 and 8.5.
These DLLS were compiled from VB.NET using VS 2012 and VS 2010 respectively.
When trying to run some custom DLLs, they fail to load in function Main with an object reference not set to an instance of an object.
All testing indicates, that the uninitialized object seems to be the global Session object which we define like this outside any function.

Public Module NXUtils
  Public theSES As Session = Session.GetSession()
  Public theUFS As UFSession = UFSession.GetUFSession()
  Public theUI As UI = UI.GetUI()
  ...
End Module

Has anyone experienced cases, where the global module variables are not getting initialized in any random way?
Yes, I said random, as our client is using 10 identical PCs (HW related) and the error happens frequently on one machine but does almost never on others!
All machines have Win7 SP1 x64 installed and until now, we haven't experienced any problem on Win10 machines.

This exact code has worked for a long time and is just giving problems recently in a non-deterministic way.
Does anyone know of any changes in NX or the .NET framework changes, or even the VS compilers which might cause something like that?
I don't have any other explanation, than this being related to memory problems as our client had sometimes complete crashes in NX or needed to kill NX as it became unresponsive.

The important snippet from the log files follows below:

...
&MACRO MENU, 0, ED_EROSION_OUTPUT UG_GATEWAY_MAIN_MENUBAR Pre actions<EDesign.tbr> ## !
Successfully loaded dynamic module C:\Program Files\Siemens\NX 8.5\UGII\nxclrldr.dll
Loaded module c:\program files\siemens\nx 8.5\ugii\nxclrldr.dll 7fee0cb0000 e000 7d60a6cf-461e46aa-1a1ca983-f482fa8b-1=nxclrldr___137696112464 version = 8.5.3.3
Using C:\Program Files\Siemens\NX 8.5\ugii\managed\ManagedLoader.dll to load managed DLL
Trying to load C:\Program Files\Siemens\NX 8.5\ugii\managed\ManagedLoader.dll
ManagedLoader.Load: C:\Program Files\Cadflow\EDesign 8.5\application\ErosionOutput.dll Name:ErosionOutput.dll
There are no context policies.

AppBase: C:\Program Files\Cadflow\EDesign 8.5\application\
Loaded assembly: ErosionOutput, Version=2.1.0.2, Culture=neutral, PublicKeyToken=null from C:\Program Files\Cadflow\EDesign 8.5\application\ErosionOutput.dll
Loaded assembly: Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a from C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualBasic\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualBasic.dll
Resolve failed: NXOpen, Version=8.5.3.3, Culture=neutral, PublicKeyToken=null
Loaded assembly: NXOpen, Version=8.5.3.3, Culture=neutral, PublicKeyToken=null from C:\Program Files\Siemens\NX 8.5\ugii\managed\NXOpen.dll
Loaded: : NXOpen, Version=8.5.3.3, Culture=neutral, PublicKeyToken=null
Loaded assembly: NXUtils, Version=2.1.0.2, Culture=neutral, PublicKeyToken=null from C:\Program Files\Cadflow\EDesign 8.5\application\NXUtils.dll
Loaded assembly: NXOpen.Utilities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null from C:\Program Files\Siemens\NX 8.5\ugii\managed\NXOpen.Utilities.dll
Resolve failed: NXOpen.UF, Version=8.5.3.3, Culture=neutral, PublicKeyToken=null
Loaded assembly: NXOpen.UF, Version=8.5.3.3, Culture=neutral, PublicKeyToken=null from C:\Program Files\Siemens\NX 8.5\ugii\managed\NXOpen.UF.dll
Loaded: : NXOpen.UF, Version=8.5.3.3, Culture=neutral, PublicKeyToken=null
Resolve failed: NXOpenUI, Version=8.5.3.3, Culture=neutral, PublicKeyToken=null
Loaded assembly: NXOpenUI, Version=8.5.3.3, Culture=neutral, PublicKeyToken=null from C:\Program Files\Siemens\NX 8.5\ugii\managed\NXOpenUI.dll
Loaded: : NXOpenUI, Version=8.5.3.3, Culture=neutral, PublicKeyToken=null
Verifying C:\Program Files\Cadflow\EDesign 8.5\application\ErosionOutput.dll for NXOpen signature.
Signed by : XXXXXXX - Cadflow XXXXXXXXXX
Successfully loaded dynamic module C:\Program Files\Siemens\NX 8.5\UGII\libnxblockstyler.dll
Loaded module c:\program files\siemens\nx 8.5\ugii\libnxblockstyler.dll 22720000 223000 b0676bf1-44b16892-68db582-1213098-1=libnxblockstyler___138074833764 version = 8.5.3.3
Loaded module c:\windows\system32\dssenh.dll 7fef9610000 32000 e7c80009-40538003-2edf6b96-5dfe09e6-2 version = 6.1.7600.16385
Loaded module c:\windows\assembly\nativeimages_v4.0.30319_64\microsoft.v9921e851#\1462297a290ab927a2b940b4ba3a4ed0\microsoft.visualbasic.ni.dll 1cd10000 224000 1462297a-b927290a-b440b9a2-d04e3aba-1 version = 14.6.1087.0
Loaded module c:\windows\assembly\nativeimages_v4.0.30319_64\system.xml\e1b804a02f2fb30bd25b986c42549a74\system.xml.ni.dll 20bc0000 892000 e1b804a0-b30b2f2f-6c985bd2-749a5442-1 version = 4.6.1087.0
Loaded module c:\windows\assembly\nativeimages_v4.0.30319_64\system.configuration\522caa5fc6794bbfd41330614abb10fc\system.configuration.ni.dll 1cbe0000 121000 522caa5f-4bbfc679-613013d4-fc10bb4a-1 version = 4.6.1087.0
Loaded module c:\windows\assembly\nativeimages_v4.0.30319_64\system.core\70ba671418b52f8f3fad72c849fdc40f\system.core.ni.dll 20230000 985000 70ba6714-2f8f18b5-c872ad3f-fc4fd49-1 version = 4.6.1087.0
Loaded module c:\windows\assembly\nativeimages_v4.0.30319_64\system\6f584662f20f93c3e7519cf468ef3889\system.ni.dll 1f660000 bd0000 6f584662-93c3f20f-f49c51e7-8938ef68-1 version = 4.6.1087.0
Loaded module c:\windows\microsoft.net\framework64\v4.0.30319\clrjit.dll 7fef5dc0000 105000 d548bd98-48f09beb-d229a4b3-5e0f7b1-2 version = 4.6.1087.0
Loaded module c:\windows\microsoft.net\framework64\v4.0.30319\nlssorting.dll bb70000 16000 d65aece-40073104-21487592-68b30321-2 version = 4.6.1087.0
Loaded module c:\windows\assembly\nativeimages_v4.0.30319_64\mscorlib\35a36d5faf5966eed2243f3d43f9f490\mscorlib.ni.dll 1e110000 14c4000 35a36d5f-66eeaf59-3d3f24d2-90f4f943-1 version = 4.6.1087.0
Loaded module c:\windows\system32\msvcr120_clr0400.dll 16d50000 f7000 55e22eca-4a71bf78-17eee7aa-6be04e68-1=msvcr120_clr0400.amd64 version = 12.0.52512.0
Loaded module c:\windows\microsoft.net\framework64\v4.0.30319\clr.dll 1d630000 990000 3517c9fe-4feb1ef0-ec120181-76639d13-2 version = 4.6.1087.0
Loaded module c:\windows\microsoft.net\framework64\v4.0.30319\mscoreei.dll bba0000 98000 691f8af9-4f7d3e58-9a71dcb3-967b2896-2 version = 4.6.1087.0
Loaded module c:\windows\system32\mscoree.dll ba90000 6f000 fb53ef9d-439ed104-b3f00399-39e02841-2 version = 4.0.40305.0
Resolve failed: NXOpen.Utilities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null
Loaded: : NXOpen.Utilities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null
Caught exception while running: Main
System.NullReferenceException: Object reference not set to an instance of an object.
   at NXUtils.NXUtils.LogError(String strWhere, Exception ex)
   at NXUtils.NXUtils.LogErrorBox(String strWhere, Exception ex)
   at ErosionOutput.ErosionOutput.Main()
&MACRO FOCUS CHANGE IN 1
&MACRO MESSAGE_BOX  -2  Error in external library. See system log for details
&MACRO MESSAGE_TEXT
&MACRO MESSAGE_TEXT  File name: C:\Program Files\Cadflow\EDesign 8.5\application\ErosionOutput.dll
&MACRO MESSAGE_TEXT
&MACRO MESSAGE_TEXT  Function name: Main
&MACRO MESSAGE_TEXT
...
3 REPLIES

Re: Start of custom DLL fails randomly

Esteemed Contributor
Esteemed Contributor

@SteveLaboutalways says to not compile for AnyCPU, but for the correct architecture, so might be an easy way for an initial test.

How about creating a debug build, so that the NX syslog also contains the offending line, when the DLL is run with the accompanying PDB file inplace, would give better hints about the problem, since I never encountered a failed initialization of a session object.

Stefan Pendl, Systemmanager CAx, HAIDLMAIR GmbH
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 (10.1.7.0) | TcVis 10.1
Development: VB.NET, Tcl/Tk    Testing: NX11.0 EAP, NX12.0 EAP

How to Get the Most from Your Signature in the Community

Re: Start of custom DLL fails randomly

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom

Thanks for the recommendation.

 

I will change the Solution Platform from "AnyCPU" to "x64" and hope that it will improve the situation.

 

In relation to the DEBUG build, I did not remember this option as I am used to develop in C++, where you link your code either against the DEBUG or RELEASE libraries, and normally there are no DEBUG libraries installed on the customer machines, so that your DEBUG builds won't run on the customer machines.

Re: Start of custom DLL fails randomly

Esteemed Contributor
Esteemed Contributor

I don't use release builds with .NET, sure there is some overhead, but I always get the information I need to correct an exception without the need to first create a debug build and then reproduce the problem.

Saves me many hours of duplicating, when the problem is hard to duplicate Smiley Wink

Stefan Pendl, Systemmanager CAx, HAIDLMAIR GmbH
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 (10.1.7.0) | TcVis 10.1
Development: VB.NET, Tcl/Tk    Testing: NX11.0 EAP, NX12.0 EAP

How to Get the Most from Your Signature in the Community