.NET Runtime 2.0 error

I keep getting .NET Runtime 2.0 errors (reported in the event log) on ​​my test machines, I try to get them when you build assemblies for anyone with more debug / diagnostic info (or fixes). Sample message:

Faulting application MyApp.exe, version 1.0.0.66, stamp 4a3851fa, faulting module kernel32.dll, version 5.2.3790.4480, stamp 49c51f0a, debug? 0, fault address 0x0000bef7.

      

My guess is that while I try not to change the interface, swapping assemblies this way is something I shouldn't be doing (should I be doing this?)

However, the install / build process for this app is healthy, and its a huge pain to rebuild and reinstall everything when issues are debugged (in fact, it's just not fesable). Is there a way to get more useful information from errors like this?

+2


source to share


3 answers


This is because the application is encountering an unhandled exception.

While this may be more in the short term, you can redesign your application to include trace information and use the tools provided in the System.Diagnostics Namespace.



For example, System.Diagnostics.Trace allows you to specify through configuration (no assembly changes) the various listener classes that can be used for the tracing runtime. You can use this to implement features that will at least help you narrow down what might be causing problems and only enable tracing on test machines.

Also, make sure you have a clean top-level exception handler. This can help you at least detect some of your stack trace data when your application is down.

+1


source


Old post, but I had this problem and was able to track down the offending code using remote debugging as described here: http://www.codeproject.com/Articles/146838/Remote-debugging-with-Visual-Studio-2010 #_rating

Similar question here: .NET Winforms app dies on startup



In my case, I had a hanlder for treeview AfterSelect that would change the treeview selection and call another AfterSelect that gets called, etc. - error that occurs: stackoverflow. This doesn't seem to happen on other machines, so it might be related to the framework.

0


source


I had the same problem with a console application; I solved it by running it from the command line, where I could see the reason for the error (in my case, DLL permissions):

Unhandled Exception: System.IO.FileLoadException: Could not load file
or assembly 'FHVI_Common, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null' 
or one of its dependencies. Access is denied. File name: 'FHVI_Common, Version=1.1.0.0,
Culture=neutral, PublicKeyToken=null' ---> System.UnauthorizedAccessException:  
    Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
    at xyzCL_Process.Main()

      

0


source







All Articles