I've developed a multithreading WPF application which is using one instance of DotNet component (namespace WPF.DotNetBrowser).
The application was running during about 21 hours of nonstop work, and then it crashed.
An undandled exeption was raised in .dll library (which was added using the docs). Visual Studio Warning (which usually describes raised exceptions) shows:
An unhandled exception of type 'lld.reworBteNtoD ni derrucco'
And further description was:
Additional information: Failed to send message GetDeviceScaleFactorMessage {type=GetDeviceScaleFactor, uid=3719442, deviceScaleFactor=0}.
Finally the application went to break mode and the 'output' tab contained the following
An undandled exception of type '' occured in DotNetBrowser.dll
So it couldn't even determine the type of exception that had been raised. I think it happens because the exception was raised in the dll file.
How can I work around this? VS was running under admin rights and the application can crash unexpectedly at any time of it's execution.
Related
I am using VS 2010. I did changes in the code to log the application exceptions. In visual studio, when I debug, I am able to log all the exceptions in the folder allotted for that. But I'm not able to log the exceptions when I publish my application. (System.StackOverFlowException occurred in mscorlib.dll) This is the error I'm getting from the published application when I'm getting an exception and I'm not able to log any application related exceptions.
You cannot catch a System.StackOverFlowException. Unless you are throw it yourself or your application runs within a debugger or other host process.
You must use a debugger to capture the exception. If the exception doesn't occur in your test setup, you should get the data the 'user' is using.
I develop native Windows 10 client LOB apps for a customer.
The environment: Windows 10 Pro (on the mobile clients / tablets and on the developer box), Visual Studio 2015 Professional with Update 3, all updates and patches installed. The client app uses the most recent „IBM MobileFirst SDK for Windows 8 Universal and Windows 10 Universal platforms“ version 8.0.2016070716
The application works very well when the application is online and the MobileFirst 8.0 server can be reached.
We are experiencing application crashes of the client app if the server can not be reached (offline, MFP server stopped).
It seems that a worker thread which is started from within the MobileFirst C# client library throws an exception. This exception can not be cathed in my code.
Here is some code to demonstrate the problem:
private async Task<WorklightAccessToken> ConnectMobileFirst()
{
try
{
IWorklightClient _client = WorklightClient.CreateInstance();
WorklightAuthorizationManager _wlauthManager =
_client.AuthorizationManager;
WorklightAccessToken temp1 = await
_wlauthManager.ObtainAccessToken("");
return temp1;
}
catch (Exception exception)
{
Debug.WriteLine("Exception occured " + exception.Message);
return null;
}
}
Create a new blank app and call the above function from the OnLaunched eventhandler.
AccessToken = await ConnectMobileFirst();
if (AccessToken != null)
{
Debug.WriteLine(AccessToken.IsValidToken
? "Connection OK, AccessToken is valid"
: "AccesToken NOT valid");
}
If the MobileFirst Server can be reached everything works as expected and the AccessToken.IsValidToken is true.
If the MobileFirst Server is offline the following happens:
the function ConnectMobileFirst() finishes and a AccessToken object is returned (no exception occurs inside the method)
the AccessToken.IsValidToken is false (which is correct, since the MobileFirst server is offline).
Sometimes before and sometimes after the program can execute the Debug.WriteLine statement a other thread hits a NullReferenceException. This „other“ worker thread started somewhere inside the ObtainAccessToken() call inside the IBMMobileFirstPlatformFoundationWin10.dll. The Output window in Visual Studio contains the following information:
Exception thrown: 'System.Runtime.InteropServices.COMException' in
mscorlib.ni.dll WinRT information: Die Serververbindung konnte nicht
hergestellt werden.
Exception thrown: 'System.Runtime.InteropServices.COMException' in
mscorlib.ni.dll WinRT information: Die Serververbindung konnte nicht
hergestellt werden.
'MFPUnhandledExc1.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded
'D:\VS2015Projects\MFPUnhandledExc1\bin\x86\Debug\AppX\System.Resources.ResourceManager.dll'.
Module was built without symbols. Exception thrown:
'System.Net.Http.HttpRequestException' in System.Net.Http.dll
Exception thrown: 'System.Net.Http.HttpRequestException' in
mscorlib.ni.dll Exception thrown:
'System.Net.Http.HttpRequestException' in System.Net.Http.dll
Exception thrown: 'System.Net.Http.HttpRequestException' in
mscorlib.ni.dll 'MFPUnhandledExc1.exe' (CoreCLR: CoreCLR_UWP_Domain):
Loaded
'D:\VS2015Projects\MFPUnhandledExc1\bin\x86\Debug\AppX\System.Runtime.InteropServices.dll'.
Cannot find or open the PDB file. Exception thrown:
'System.Net.Http.HttpRequestException' in mscorlib.ni.dll Exception
thrown: 'System.Net.WebException' in System.Net.Requests.dll Exception
thrown: 'System.NullReferenceException' in
IBMMobileFirstPlatformFoundationWin10.dll
If you set a breakpoint on the line after the ConnectMobileFirst() call you can see there is a worker thread still active which has IBMMobileFirstPlatformFoundationWin10.dll in its call stack. This thread is not here anymore, if the backend connection is OK.
This behaviour can also be seen not only if the MobileFirst Server is offline but if the server is slow responding or the network is slow and the server response is big. Also this is not only during connect, but also during WorklightResourceRequest.send().
My questions:
What can I do to prevent this stray thread from killing my application? (a short term solution)
Why is there still a worker thread even if the call to ObtainAccessToken() has already finished?
And why is this thread not handling its exceptions?
This is found as a bug in our client SDK code.And we have fixed it in the issue https://www-304.ibm.com/support/entdocview.wss?uid=swg1PI68253.
The fix will be published and will be available in nuget in the next nuget release.
What can I do to prevent this stray thread from killing my application?
Take a look at the Application.UnhandledException event, you can find documentation for this on MSDN via the below link. You can wire up this event in the App.xaml.cs code behind.
Normally after the UnhandledException event is fired, the Windows Runtime terminates the app because the exception was unhandled. The app code has some control over this: if the UnhandledException event handler sets the Handled property of the event arguments to true, then in most cases the app will not be terminated.
https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.application.unhandledexception
In regards to your other questions, I think you should have a read of this MSDN article on Exception handling for Windows Runtime apps in C# or Visual Basic which will help you understand what is going on with these exceptions in your app.
https://msdn.microsoft.com/en-us/library/windows/apps/dn532194
We are able to reproduce the issue and we are working on the fix. We will update once we release the new version of SDK.
I have a WPF application(.net 4.0) which is working fine on Windows 7 systems. But when I try to run the application windows 8.1 it is working fine for 15 to 20 mins but after that suddenly a popup message is showing like
A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available
popup message showing with two options Debug and close program. When I press debug it is showing message as FatalExecutionEngineError detected
The runtime has encountered a fatal error. The address of the error was at 0x713543ed, on thread 0x23624. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
if i press continue further showing message as
An unhandled exception of type 'System.ExecutionEngineException' occurred in PresentationFramework.dll
But i didn't get the exact reason why it is failing and which portion of code is causing the problem?
After searching over the net i have tried the following
Added DispatcherUnhandledException handler and App domain Unhandled exception handler and also added legacyUnhandledExceptionPolicy to . But nothing is works for me still facing the crash on Windows 8.1
Can someone point me how to detect the code portion which causing the crash? and How to handle FatalExecutionEngineEror exception?
EDIT
CLR version Used in both windows 7 and 8.1 is 4.0.30319
I'm using VS 2008. I have a C# application.
When I try to build/run the project it opens the JUST IN TIME debugger for some reason disabling me from stepping through my code where the exception occurred.
How can I get rid of this JUST IN TIME prompt?
I did go to tools=>options-->debugging and disabled JUST IN TIME and now it is giving me an error message:
an unhandled win32 exception occurred in projectname. just in time debugging this exception failed with the following error...basically i guess it's trying to open just in time
How do I get normal compiler debugging capabilities?
Check out the following MSDN article: Just-In-Time Debugging. It sounds like in your case, you might want to make sure you have registry keys for JIT deleted.
Also, the following seems to be applicable in your case:
An unhandled win32 exception occurred in . Just-In-Time
debugging this exception failed with the following error: The logged
in user did not have access to debug the crashing application.
This message indicates that Just-In-Time debugging failed because you
do not have proper access permissions. For information on the required
permissions, see [Obsolete] Remote Debugging Permissions.
I am trying to find how to take a crash dump of a .Net managed executable and then open the resulting .dmp file in Visual Studio 2008. I want to see where in the source code the exception is thrown, the call stack and the value of variables in functions on the stack.
To simplify the problem, I've written a mini-app that crashes:
...
class Program
{
static void Main(string[] args)
{
int a = 2; //Variable I want to see value for when debugging
if (!File.Exists(#"C:\Crasher\bin\Debug\file.txt")) //Doesn't exist
throw new FileNotFoundException(); //Unhandled exception thrown
}
}
...
I did a DEBUG build and ran it from outside Visual Studio. In windbg, I clicked "Attach to Process" and selected my app. Then I typed in the windbg command window:
.dump /ma C:\crasher\bin\debug\dump.dmp
Then I opened the .dmp file in Visual Studio. I went to Tools->Options->Debugging->Symbols and added the following:
http://msdl.microsoft.com/download/symbols (saved to local folder)
This gives me symbols for all of the DLLs listed in the Modules window (e.g. Kernel32.dll, gdi32.dll - I think all of them listed are native) with the exception of mscorlib.ni.dll. The Microsoft Symbol Server gives me symbols builds and .pdbs for mscorlib.dll but NOT mscorlib.ni.dll.
When I try to load the .pdb for my .exe itself, it tells me it does not match the app. I think this is because the .exe is managed and we don't yet have symbols for all of the native code beneath it - i.e. if I could get a symbols build and pdb for mscorlib.ni.dll this would work.
Is this reasoning correct? Am I missing something else?
Either way, why is mscorlib.ni.dll not available on the Microsoft Symbol Server, where can I get symbol information and is there anything else I should know for debugging managed code through crash dumps in Visual Studio.
Many thanks - any help will be appreciated.
Phil Whittington
As Jason Evans says in his comment, this is not supported in VS2008, but you can do it in WinDbg.
The easiest way to get a correct dump for a crash like this is to use adplus (which is included in Debugging Tools for Windows). There are various options, but to get a crash dump based on the process name, you could do
>adplus -crash -o c:\dumpdirectory -pn app.exe
This will give you two dumps. One for the first chance exception and one for the second. In this case they will be virtually identical, but for a more realistic scenario the first chance exception dump will show you the state of the application when the exception was thrown (i.e. before any exception handling occur). The second chance exception dump will show you the state of the unhandled exception.
To get the exception, open the crash dump and load SOS by typing .loadby sos mscorwks.
Then use the !pe command to print the exception on the current thread (which will be the faulting thread in this case). It will look something like this:
0:000> !pe
Exception object: 024a5114
Exception type: System.IO.FileNotFoundException
Message: Unable to find the specified file.
InnerException: <none>
StackTrace (generated):
SP IP Function
0020F0F0 005100D6 TestBench!TestBench.Program.Main()+0x66
StackTraceString: <none>
HResult: 80070002
To list the local variable a use !clrstack -l, but keep in mind that locals are rarely available in a release mode builds due to optimizations.
0:000> !clrstack -l
OS Thread Id: 0x1a50 (0)
ESP EIP
0020f04c 7571b727 [HelperMethodFrame: 0020f04c]
0020f0f0 005100d6 TestBench.Program.Main()
LOCALS:
0x0020f0fc = 0x00000002 <--- the value of a
0x0020f0f8 = 0x00000000
0020f328 51141b5c [GCFrame: 0020f328]