Microsoft Visual C ++ Runtime Error in Python

I have a python program that runs on the server continuously, and it puts some data into the MYSQL database and loads some. It also uses a TCP / IP connection. The problem is that after about 24 hours a runtime error occurs:

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, the python shell closes. And when I close all the python files and check the Windows task manager, I see that the pythonw.exe file is open there.

I am using IDLE to run my application.

+7
source share
3 answers

Problem

This application requested Runtime to complete it in an unusual way.

If you ever received this error when starting a Windows application, it is most likely because the abort() procedure was called somewhere in your python library and even possibly from your python runtime. For more information and abort call behavior, refer to the MSDN documentation for aborting

Demo

You will need

Create a C DLL that calls abort() , and then call that DLL using ctypes

abort_dll.h header 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 create your DLL (in both Debug and Release Version).

Assuming my dll files are present in the following location

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

Run the following code in your IDLE

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

You will definitely see the following popup

enter image description here

The only difference in your case is that it gives you the notorious option [Abort | Retry \ Ignore]. It was only because I used the Debug version of my DLL. Instead, if I were to use the release version, I would usually see

enter image description here

Decision

On Windows AFAIK, you cannot handle SIGABRT with a signal handler. So, the only bet is to use JIT, which I suppose you have already installed. then you will see the following popup.

enter image description here

If you select Debug, this will open the installed JIT debugger. After that, you can discard the failed stack and identify the failed module. After that, you can map what could be a python module that could call the module.

+4
source

In my previous answer, I tried to talk about the reason for reporting behavior and how you can debug and determine the root cause. Unfortunately, this requires extensive knowledge and debugging time.

Alternatively, Process Monitor can help you understand the level of the problem at a high level that the User might need.

Necessary tools

Debugging Steps

  • Workflow monitor
  • Add the following filters (Cntrl + F)

    • Process name - starts with - python
    • Operation - starts with - CreateFile

    enter image description here

  • Now keep running procmon until your application runs
  • Stop Capture (Cntrl + E)
  • LOG search to call WerFault.exe

    enter image description here

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

  • Now use the knowledge of the Python library or ask (including SO) to determine what might be a failure. Even from the journal, you can determine which Python module named this DLL by scrolling further.
+2
source

I was able to fix the same problem by excluding triggered but not displayed graphs. 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 will fix this 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 is no longer displayed.

0
source

All Articles