vshost-clr2.exe has stopped working

Question

I'm working on an app in VS 2010 on wind2008. It's a .Net 3.5 app that use .Net 2.0 library.

I change all Frameworks to 3.5 .Net and uncheck "Enable the visual studio hosting process"

But When I debug my solution I got this error :

    Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: AnalyseFarm.exe
  Application Version:  1.0.0.0
  Application Timestamp:    5326f157
  Fault Module Name:    KERNELBASE.dll
  Fault Module Version: 6.1.7600.16385
  Fault Module Timestamp:   4a5bdfe0
  Exception Code:   c000041d
  Exception Offset: 000000000000aa7d
  OS Version:   6.1.7600.2.0.0.274.10
  Locale ID:    1036
  Additional Information 1: 5ecb
  Additional Information 2: 5ecbd308407466ba89616cb69c9e62d8
  Additional Information 3: 9ac0
  Additional Information 4: 9ac06af1219db569f0ee193c24745b31

any idea , beast regards

Answer 1

Exception Code: c000041d

This tells the tale, that's STATUS_FATAL_USER_CALLBACK_EXCEPTION, "An unhandled exception was encountered during a user callback". Your program threw an exception and it wasn't handled. Which normally automatically breaks into the debugger and displays the Exception Assistant.

However, the exception occurred at a very awkward time, just when the operating system was in a state where it cannot afford to go through the normal rigamarole that it goes through when a thread dies with an exception. This kind of mishap usually occurs when the callback was triggered by 32-bit code but the exception occurred in 64-bit code, there's no good mechanism to marshal 64-bit exceptions back into 32-bit code, the exception information cannot be properly interpreted by such code since it includes 64-bit pointer values. Or the other way around. Windows messages generated by the window manager tend to fall in this category. Beware that this is just a rough guess at the reason, you need to find the real one.

You do so by forcing the debugger to stop at the code where the exception is thrown, before the operating system is asked to deal with it. Use the Debug + Exceptions dialog, tick the Thrown checkboxes to force the debugger to stop at the throw location.