Microsoft Visual C++ Runtime Error in Python

Question

I have a python program that runs in a server continuously and it puts some data into MYSQL dataBase and load some. It is also using TCP/IP connection. the problem is that after about 24 hrs it gives a runtime error:

Microsoft Visual C++ Runtime Library!

Runtime Error!

Program: C:\python27\pythonw.exe

This application has requested the Runtime to terminate it in an unusual way.

And I hit OK python shell closes. And when I close all python files and check Windows Task Manager I see still there is a pythonw.exe file open there!!!

I am using IDLE to run my application.

Answer 1

Problem

This application has requested the Runtime to terminate it in an unusual way.

If you ever receive this error while running a windows application, it is most possibly because somewhere in your python library, and even possible from your python runtime, abort() routine was called. For more information, and the behaviour of calling abort please refer the MSDN documentation on abort

Demo

You would need

1. Visual Studio 2008 (Express Edition)
2. Setting the Microsoft Symbol Server correctly in _SYM_PATH
3. Python 2.7
4. Install WinDBG, and set it up as JIT

Create a C DLL which calls abort() and then call this DLL using ctypes

Header File abort_dll.h

#include<cstdlib>
#include <windows.h>

extern "C"  __declspec(dllexport) void call_abort(void);

Source abort_dll.cpp

#include "abort_dll.h"

__declspec(dllexport) void call_abort(void)
{
    abort();
}

Source dllmain.cpp

#include "abort_dll.h"
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

Now Compile and Build Your DLL (both in Debug and Release Version).

Assuming my DLLs are present in the following location

Debug Version: C:\TEMP\Debug\abort_dll.dll Release Version: C:\TEMP\Release\abort_dll.dll

Execute the following code in your IDLE

from ctypes import *
hDLL = WinDLL(r"C:\TEMP\Debug\abort_dll.dll")
hDLL.call_abort()

You are sure to see the following Popup

The only difference with your case is, it gives you the infamous option [Abort|Retry\Ignore]. It was only because I had used a Debug version of my DLL. Instead, if I had used a release version, I would typically see

Solution

In Windows, AFAIK you cannot handle the SIGABRT with a signal handler. So, the only bet is to use the JIT, that I suppose you had already installed. you would then see the following pop up.

If you would select Debug, that will open your installed JIT debugger. After which, you can dump the failing stack, and determine the failing module. Once done, you can then correlate what could be the python module that might have called the module.

Answer 2

I was able to fix the same issue by eliminating the initiated, yet not displayed plots. It was:

plt.plot(dI_new[ref:idx_stop], w_new[ref:idx_stop], 'ro') #x,y
plt.xlabel('Strain')
plt.ylabel('Stress, kPa')
##plt.axis([0, 6, 0, 20])
##plt.show()

I fix it for:

##plt.plot(dI_new[ref:idx_stop], w_new[ref:idx_stop], 'ro') #x,y
##plt.xlabel('Strain')
##plt.ylabel('Stress, kPa')
##plt.axis([0, 6, 0, 20])
##plt.show()

The error doesn't show up anymore.

Answer 3

In my former answer, I tried to introduce about the reason for the reported behavior and how one can debug and determine the root cause. Unfortunately, this requires an extensive debugging knowledge and time to isolate the problem.

Alternatively, Process Monitor can some handy to give a high level understanding of the problem, which as a User would post possibly need.

Tools Required

1. Process Monitor

Steps to Debug

1. Run Process Monitor

2. Add the following filters (Cntrl + F)

   1. Process Name - begins with - python
   2. Operation - begins with - CreateFile

   

3. Now keep running procmon, until your application Crashes
4. Stop Capture (Cntrl + E)

5. Search the LOG for a call to WerFault.exe

   

6. Gradually scroll up to see the last called Non Windows DLL which may be related to Python. In the above case, its abort_dll.dll.

7. Now use your Python library knowledge, or ask across (including SO), to determine, what could be the failing. Even, from the log, you can identify, which Python Module called this DLL by scrolling further up.