AppCrash Issue related to COM?
-
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: be03a
-
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: be03a
Tony Tullemans wrote:
Does this sound like a reasonable hypothesis?
No. Why, because if this was the case we would expect to see crashes occurring everywhere and all the time. The only way to identify what is happening is to add some debug code to your application so you capture more information prior to the crashes occurring.
-
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: be03a
That's not how paging works, addresses will be preserved. Get as many crash dumps as you can from the client and start debugging.
Steve
-
Tony Tullemans wrote:
Does this sound like a reasonable hypothesis?
No. Why, because if this was the case we would expect to see crashes occurring everywhere and all the time. The only way to identify what is happening is to add some debug code to your application so you capture more information prior to the crashes occurring.
Thanks for your reply Richard, but the problem is that the AccessViolationException very rarely ever occurs when the application is running within the VS development environment, and furthermore it does not occur on all client computers. The only common factors I have been able to establish is that (1) the user has had the program running for several hours, and (2) the user has just switched back to my application after using some other program. I have come to this forum in the hope that anyone who may have experienced similar errors may give me some clue as to what to look for. I have literally spent over one hundred hours trying to debug this issue.
-
Thanks for your reply Richard, but the problem is that the AccessViolationException very rarely ever occurs when the application is running within the VS development environment, and furthermore it does not occur on all client computers. The only common factors I have been able to establish is that (1) the user has had the program running for several hours, and (2) the user has just switched back to my application after using some other program. I have come to this forum in the hope that anyone who may have experienced similar errors may give me some clue as to what to look for. I have literally spent over one hundred hours trying to debug this issue.
You have my sympathy, but unfortunately the only way to track this sort of error is to add logging and debugging code to your application. I worked in technical support for many years and often saw problems such as you describe, and yes, they were extremely difficult to diagnose.