none
AccessViolationException with HandleProcessCorruptedStateExceptions not handled at runtime RRS feed

  • Question

  • I am calling a third-party unmanaged DLL from vb.net (framework 4.5) and on rare occasions the third party DLL thows an AccessViolationExcpetion ("Attempted to read or write protected memory. This is often an indication that other memory is corrupt."). 

    I have added the <HandleProcessCorruptedStateExceptions> attribute to the method which calls the DLL as follows: -

        <Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions> _
        <SecurityCritical> _
        Private Sub CallThirdParty()
                Try
                    UnmanagedFunction(_outputFilename) ' this is the referenced with a DLLImport
                Catch ex As Exception
                    ' example code to demonstrate handler
                    Environment.Exit(0)
                End Try
        End Sub

    When running in debug mode in VS2013 the exception is handled and the application quits as expected. However when I build and run the app outside of VS2013 it just hangs at this point and no exception is handled. The program doesn't even crash.

    Is there anything I have missed here which makes debug vs build different?

    Thanks for reading this...

    Friday, January 24, 2014 10:59 AM

All replies

  • Hi Paraj,

    You can track this down with the help of WinDBG and SOS. http://msdn.microsoft.com/en-us/library/windows/hardware/hh406283(v=vs.85).aspx.

    I have read countless times how this issue can be caused by firewalls or antivirus. So if possible, you can build a virtual machine to run your app without firewalls and antivirus and see what happen.

    Here is a workaround you can take a look, http://stackoverflow.com/questions/3469368/how-to-handle-accessviolationexception.

    At last, I pick up some articles about debug and hang.

    http://blogs.msdn.com/b/anandbms/archive/2005/03/03/384748.aspx.

    http://blogs.msdn.com/b/msdnts/archive/2006/11/24/how-to-debug-application-crash-hang-in-production-environment.aspx.

    Hope useful to you.

    Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, January 27, 2014 1:55 AM
    Moderator
  • Thanks for taking the time to look into this and reply. I really appreciate that.

    So to answer your points, we don't want to track the reason for the crash as the third party DLL cannot be modified anyway, even if we knew why it's crashing.

    There are no firewalls or antivirus getting in the way (I am running this on my local dev machine).

    I looked at the workaround link, and we have tried implementing all of these but still the issue persists - like I say debugging with VS catches the exception and everything works as expected - it's only when building and running the EXE that the hang occurs.

    So the question remains - do you know why this is caught and handled debugging in VS, but not when compiled and ran without debug? Is there anything I can add to the build configuration to help catch this exception apart from the things you've mentioned, which I've tried?

    Tuesday, January 28, 2014 1:22 PM
  • Based on my experiance, for AV exception, the appllication usually crashes insteading of hang. Have you check the callstack of the crashing, in .NET, if the CLR run time threw critical exception such as managed heap corrupt, usually this can't be handled.

    However to catch native exeption, maybe you can use the following patern.

    See CA2102: Catch non-CLSCompliant exceptions in general handlers

    try {
    } catch (Exception ex) {
       
    // .NET exception
    } catch {
       
    // native exception
    }
      


    Friday, February 14, 2014 2:00 AM
  • Take a dump of the process when it hangs and see what it is doing. Or debug the process using non-invasive debugger (like windbg or maybe even VS Attach to Process could work).

    Another option: Create a small repro (with your own native DLL that will just dereference wild pointer and AV) and see if you get the same behavior. AFAIK default behavior should be process shutdown with potential Watson dialog appearing.

    -Karel

    Thursday, March 6, 2014 9:02 PM
    Moderator