I’m working on a legacy system that involves a Classic ASP web application. This application creates a “global” instance of a VB6 application (.exe) that utilizes a COM DLL written in C++ to respond to client requests.
Here is a simplified flow of the system:
- A client sends a request to the ASP page.
- The ASP page interacts with a VB6 application.
- The VB6 application uses a C++ COM DLL to process the request and return a response.
Recently, I’ve been facing a serious issue:
- There is an error in the C++ COM DLL (likely a segmentation fault or insufficient memory issue), causing the application to end in invalid state.
- When this error occurs, the ASP page somehow catches the unhandled exception, but instead of terminating the VB6 application process a let the system to generate crash-dump, it leaves it in a “zombie-mode.”
- In this zombie mode, the process manager reports the VB6 application using only about 2 MB of RAM, whereas it should be using at least 600 MB.
Here are the problems I need help with:
- How can I ensure that when the C++ COM DLL crashes, the VB6 application process inside “ASP Classic” generates crash-dump like any other process?
- Could the problem be related to how Classic ASP handles exceptions, or is it more likely an issue with the VB6 application?
Any advice on how to handle these crashes more gracefully and gather more diagnostic information would be greatly appreciated.