I am trying to track down an error occurring on a target machine running Windows 7 64-bit for a C# WinForms application written in Visual Studio 2008. All I have to go on is the Windows Error Reporting output from the Event Viewer. I found a lot of helpful information here: http://www.codeilove.com/2012/09/debugging-using-windows-error-reporting.html.
Problem signature:
P1: myprogram.exe // filename of the executable
P2: 1.44.0.0 // assembly version for the executable in P1
P3: 560be2df // assembly timestamp for the executable in P1
P4: mscorlib // assembly where the fault occurred
P5: 2.0.0.0 // assembly version for the assembly in P4
P6: 4ca2b889 // assembly timestamp for the assembly in P4
P7: c43 // token for the method where the fault occurred
P8: 59 // IL offset into the method specified in P7
P9: System.FormatException // name of the exception that caused the fault
From the link it appears that P7, P8, and P9 are the most important, and that I should be able to find the method def for "c43" using ILDASM by looking for 06000c43. In C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll I find the following in System.Number:
.method /*06000C43*/ assembly hidebysig static
uint64 ParseUInt64(string 'value',
valuetype System.Globalization.NumberStyles/*020003B6*/ options,
class System.Globalization.NumberFormatInfo/*020003B5*/ numfmt) cil managed
Based on this information there is a System.FormatException occurring in System.Number.ParseUInt64, right? I have searched through my project in Visual Studio, and I can't find any instances where my code calls this function. Where do I go from here?
I have a top-level exception handler for Application.ThreadException that logs unhandled exceptions to a file. In this case I am getting an application crash and nothing in my log file. Is it safe to assume this Exception is happening in a thread other than my UI?
Starting with Vista SP1 you can configure Windows Error Reporting to collect local crash dumps. Just set registry settings on the target machine as described in that article and wait till your program crashes again. After that, check the directory that you've configured as DumpFolder. You should find a .dmp file in there. Open it in WinDbg or with Visual Studio and you should be able to see a full stack trace of where the exception happened.
Related
I have a Windows Console application that accesses our SQL database. This app works fine from VS2019, the debug folder and the release folder. However, if I publish this app, the installed version fails with the exception shown below.
I do note the following differences between the installed location (\AppData\Local\2.0\xxx\yyy) and the \Release folder:
The \Release folder has SNI files in the \x86 and \64 directories, but the installed directory is missing this information. How do I include this in the manifest? I suspect that this is the main issue causing the exception.
The manifest file in the installed location is missing information related to Identity - not sure if this is a concern, but perhaps it is?
Application: SmartRView Configuration.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ComponentModel.Win32Exception
at Microsoft.Data.SqlClient.SNINativeMethodWrapper..cctor()
Exception Info: System.TypeInitializationException
at Microsoft.Data.SqlClient.SNINativeMethodWrapper.SNIInitialize()
at Microsoft.Data.SqlClient.SNILoadHandle..ctor()
at Microsoft.Data.SqlClient.SNILoadHandle..cctor()
Exception Info: System.TypeInitializationException
at Microsoft.Data.SqlClient.TdsParser..cctor()
Using the tutorial from the developers at Microsoft, I followed the tutorial created at https://learn.microsoft.com/en-us/dotnet/machine-learning/tutorials/object-detection-onnx.
I made sure to install CUDA V10.1.243 and cuDNN 7.6.5 from Nvidia's site.
Yet somehow, even after copying the entire contents of C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\bin to my project binary's directory at machinelearning-samples\samples\csharp\end-to-end-apps\ObjectDetection-Onnx\OnnxObjectDetectionApp\bin\Debug\netcoreapp3.0, I keep running into the following error while compiling the example program MS provided: Exception thrown: 'System.DllNotFoundException' in System.Private.CoreLib.dll An exception of type 'System.DllNotFoundException' occurred in System.Private.CoreLib.dll but was not handled in user code Unable to load DLL 'onnxruntime' or one of its dependencies: The specified module could not be found. (0x8007007E).
This should make sure they are accessible from the PATH right? I'm also including their original location in NVIDIA GPU Toolkit in the system PATH as well. I am using the latest version of Visual Studio 2019 to load and compile this solution. Is there anyone out there that has been able to run this code successfully, and if so, how?
tl;dr Q. "how do we successfully deploy [unmanaged library] libzmq to load dynamically to support 'ZeroMQ CLR namespace' being used in a C# program?"
C# code with NuGet pkg ZeroMQ 4.1.0.17 (Runtime version v4.0.30319; Version 4.1.0.42169) installed. Works just fine running in the Visual Studio workspace but when deployed with the .exe in the same directory as the ZeroMQ.dll and with an amd64 subdirectory containing both libzmq.dll and libsodium.dll -- and even with copies of both those copied up into the same exec directory as program and ZeroMQ.dll -- we get:
Connect System.TypeInitializationException: The type initializer for 'ZeroMQ.lib.zmq' threw an exception. ---> System.IO.FileNotFoundException: UnmanagedLibrary[libzmq] Unable to load library "libzmq" from "C:\Windows\TEMP\libzmq.dll". Inspect Trace output for details. ---> System.IO.FileNotFoundException: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
--- End of inner exception stack trace ---
at ZeroMQ.lib.Platform.Win32.LoadUnmanagedLibrary(String libraryName)
at ZeroMQ.lib.zmq..cctor()
--- End of inner exception stack trace ---
at ZeroMQ.ZContext..ctor()
at Core.Adapter.ZeroMQ.ZeroMQMessagingService.Connect(String connection_string) in \ZeroMQMessagingService.cs:line 201
Note that is says it is looking in C:\Windows\TEMP but maybe that is only the last place in a chain.
We're getting this after upgrading to ZeroMQ 4.1.0.21 and failing to load the libzmq.dll as an "embedded resource", so we removed .21 completely and returned to .17. It had been working fine in .17 before we upgraded to .21.
Copy If Newer is checked on the amd64\libzmq.dll and libsodium.dll and, yes, this is an x64 build attempting to run on an x64 machine. The failing host is 2012 Server running .NET 4.5.
This turned out to be very simple. We are moving to a new machine still being configured and installing the C++ 2010 redistributable solved the problem for us.
I am trying to provide a colleague with a dll that is from my build so she can execute with the changes i have made. Unfortunately she gets the following error
The system was unable to launch the requested screen. --->
Unable to display screen.
---> System.IO.FileLoadException: Could not load file or assembly 'file:///name.dll' or one of its dependencies. Operation is not
supported. (Exception from HRESULT: 0x80131515) --->
System.NotSupportedException: An attempt was made to load an assembly
from a network location which would have caused the assembly to be
sandboxed in previous versions of the .NET Framework. This release of
the .NET Framework does not enable CAS policy by default, so this load
may be dangerous. If this load is not intended to sandbox the
assembly, please enable the loadFromRemoteSources switch
Now if she were trying to run it in visual studio i could set the loadFromRemoteSources switch - however this dll is replacing a dll in an install version on a vagrant box. How can i enable the dll to run in this scenario?
Thanks
I'm trying to decipher the meaning on the P1...P10 parameters associated with a clr20r3 that is written to the event log when my application experiences an exception.
The best I've been able to find is:
P1: the hosting process (e.g. w3wp.exe)
P2: the hosting process version (e.g. 6.0.3790.1830)
P3: ??? (e.g. 42435be1)
P4: the assembly from which the exception was raised (e.g. mrtables.webservice)
P5: the assembly version (e.g. 2.1.2.0)
P6: ??? (e.g. 4682617f)
P7: ??? (e.g. 129)
P8: ??? (e.g. 50)
P9: the exception type raised (e.g. system.argumentexception)
P10: ??? (e.g. NIL)
Googling for clr20r3 provides thousands of sample parameter values, from which someone can try to derive a pattern.
But I'm hoping for documentation on the parameter meanings, as opposed to educated guesses.
Edit: While I can hope for canonical documentation, really I'd be happy to see the exception being thrown, at what line, complete with a stack trace.
Bonus Reading
Unhandled exception that caused the application to crash with "EventType clr20r3, P1 w3wp.exe" in the log, but no details there (asking for help with a problem, while we're asking for a canonical explanation of what the parameters mean)
P7 and P8 are the important ones to find out where the P9 exception was raised. Use P4 to know what assembly to look for. Run ildasm.exe and open that assembly. File + Dump, tick the "Token values" checkbox, OK and save the .il file somewhere.
Open the file in a text editor. P7 gives you the method token, it starts with 0x06, producing token value "06000129". Search for:
.method /*06000129*/
Which gives you the method name, look up from there to find the .class, that gives you the class name.
P8 gives you the IL offset. From the found .method, look for IL_0050 for the instruction that raised the exception. Mapping it back to your source code is a bit tricky but you'll probably figure it out. Use Reflector if necessary.
In general, write an event handler for AppDomain.UnhandledException to avoid the pain of reverse-engineering these Watson crash buckets. Log the value of e.ExceptionObject.ToString() to get both the exception message and a stack trace.
Here is the information on Watson Buckets
Exe File Name
Exe File assembly version number
Exe File Stamp
Exe file full assembly name
Faulting assembly version
Faulting assembly timestamp
Faulting assembly method def
Faulting method IL Offset within the faulting method
Exception type
And also here is a MSDN article on the same.
Sample:
Problem Signature 01: devenv.exe
Problem Signature 02: 11.0.50727.1
Problem Signature 03: 5011ecaa
Problem Signature 04: Microsoft.VisualStudio.SharePoint.Project
Problem Signature 05: 11.0.60226.0
Problem Signature 06: 512c2dba
Problem Signature 07: 18a8
Problem Signature 08: 1d
Problem Signature 09: System.NullReferenceException