none
AppCrash Issue RRS feed

  • Question

  • Greetings!

    I have a complex scheduling application written in VB.NET (.NET Framework 4.0) that must use a Data Access Layer consisting of a bunch of C++ DLLs which are in-turn accessed via a COM API library. Of course when the COM API is referenced in the VB.NET application an Interop Assembly is created by Visual Studio.

    The problem I am having is that some users are experiencing an APPCRASH (c0000005 exception code) several times per day, but this only occurs if they have the my application open all of the time and they are continually moving between it  and other apps (e.g. to MS Word or MS Outlook etc).  The APPCRASH occurs as soon as the shift their focus back to my application.  I do have a suspicion as to why this may be occurring but my lack of knowledge of the way in which Windows and the .NET Framework manage memory precludes me from being sure.

    My suspicion is that when users are using other applications for some time, and Windows requires more memory for those other apps, that it caches my app’s memory to disk.  When they return to my app then Windows loads it back into memory, but because I am using COM it is placing the COM related memory into a different address and then when my app attempts to access the COM objects then an Access Violation is occurring and hence the APPCRASH.  The faulting module is nearly always the COM API library, but sometimes it is ntdll.dll or clr.dll.

    Does this sound like a reasonable hypothesis?  And if so, what are my options (if any) for resolving this?

    Here are a sample of problem signature traces. Note that they do not all have the same faulting module.

    Signature du problème :
    Nom d’événement de problème: APPCRASH
    Application Name: VM2305.EXE
    Application Version: 2.1.0.5
    Application Timestamp: 4f44820b
    Fault Module Name: a4wcomex.dll
    Fault Module Version: 6.0.0.0
    Fault Module Timestamp: 4cfb1354
    Exception Code: c0000005
    Exception Offset: 0001de92
    Version du système: 6.0.6002.2.2.0.768.3
    Identificateur de paramètres régionaux: 3084

    Problem signature:
    Problem Event Name: APPCRASH
    Application Name: VM2305.EXE
    Application Version: 2.1.0.9
    Application Timestamp: 4fa218fd
    Fault Module Name: clr.dll
    Fault Module Version: 4.0.30319.261
    Fault Module Timestamp: 4ec9f6ff
    Exception Code: c0000005
    Exception Offset: 00020ed1
    OS Version: 6.1.7601.2.1.0.256.48
    Locale ID: 4105
    Additional Information 1: 93e2
    Additional Information 2: 93e2ab0171a7a6ff1415f9bd2ed3bdf7
    Additional Information 3: be03
    Additional Information 4: be03af409f1ea363e69fa074d659b668

    Problem signature:
    Problem Event Name: APPCRASH
    Application Name: VM2305.EXE
    Application Version: 2.1.0.10
    Application Timestamp: 4faca846
    Fault Module Name: StackHash_0a9e
    Fault Module Version: 0.0.0.0
    Fault Module Timestamp: 00000000
    Exception Code: c0000005
    Exception Offset: 08000400
    OS Version: 6.1.7601.2.1.0.256.48
    Locale ID: 3084
    Additional Information 1: 0a9e
    Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
    Additional Information 3: 0a9e
    Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

    Problem signature:
    Problem Event Name: APPCRASH
    Application Name: VM2305.EXE
    Application Version: 2.1.0.10
    Application Timestamp: 4faca846
    Fault Module Name: StackHash_0a9e
    Fault Module Version: 0.0.0.0
    Fault Module Timestamp: 00000000
    Exception Code: c0000005
    Exception Offset: 41080414
    OS Version: 6.1.7601.2.1.0.256.48
    Locale ID: 3084
    Additional Information 1: 0a9e
    Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
    Additional Information 3: 0a9e
    Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

    Problem signature:
    Problem Event Name: APPCRASH
    Application Name: VM2305.EXE
    Application Version: 2.1.0.16
    Application Timestamp: 4fea898a
    Fault Module Name: a4wcomex.dll
    Fault Module Version: 6.0.0.0
    Fault Module Timestamp: 4cfb1354
    Exception Code: c0000005
    Exception Offset: 0001de92
    OS Version: 6.1.7601.2.1.0.256.48
    Locale ID: 4105
    Additional Information 1: 0a9e
    Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
    Additional Information 3: 0a9e
    Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

    Friday, January 25, 2013 12:00 AM

All replies

  • Hi Tony,

    Welcome to the MSDN Forum.

    I am trying to involve some other one into this case, it will take some time, wait it patiently, please.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, January 28, 2013 6:24 AM
    Moderator
  • No, I don't agree with your hypothesis. Memory paged out by Windows gets restored at the exact same virtual addresses as it was paged out of. Every processes has it's own private virtual address space that no other user process will generally touch.

    You need to configure the machines to capture process dumps of the crashes so you can see the callstacks. The eventlogs aren't enough to diagnose.

    Crashes in ntdll from a managed app would lead me to suspect interop -- and you are using COM. Heap corruption may be occurring. Somewhat random errors also might infer memory corruption.

    Wednesday, January 30, 2013 9:54 PM