On Windows7 I have a python script that uses Windows DLLs, using the .NET Common Language Runtime (CLR). An error occurs inside one of the used DLL, but the standard Python debugger only debugs on the Python code level (and not the DLL).
How can I debug what is going on inside the DLL(s)?
If you have Microsoft Visual Studio available,
1) open the Visual Studio project that your DLL is part of (or create a new project).
2) If you have set up your DLL for debugging (you've built it with debugging info, and it will be the one that your python program will use), you can set breakpoints in the DLL code.
3) Start the program you want to debug as you would do normally.
4) Go back to the Visual Studio IDE and go to the Debug menu. Choose the Attach to Process option. You will then get a list of all the running processes.
5) Choose the process you want to debug, which will be your python program, or runtime that is running your program.
6) Sit back and wait for one of your breakpoints to be hit, or you can try a Break All from the Debug menu to temporarily halt the program.
This is a general way of starting out debugging not only python programs, but any program where you need to debug a DLL that is being used by the program.
Note that the above advice works best if you have built the DLL yourself with debugging information and is being utilized by your python application. If it is a third-party DLL where you have no source code, you can still debug from Visual Studio, but will need to know assembly language (since the source code is usually not available).
These 3 debugging scenarios with pythonnet are based on PTVS docs:
https://github.com/pythonnet/pythonnet/wiki/Various-debugging-scenarios-of-embedded-CPython
Related
My end goal is to debug a Python script which calls my own COM dll written in C++. Using Python 3.8, in MS Visual Studio Community 2019.
My main problem is debugging. MSVC is constantly asking for debug symbols for Python38.dll, and failing to hit breakpoints.
In my Python project, Debug Properties, if DO NOT check 'Enable Native Code Debugging', then my Python runs and stops correctly at breakpoints that I have set. The COM dll is failing on an assertion (which is what I am trying to debug), and I get the option to 'Retry to Debug' ... but nothing happens, and my python code ends (The program 'python3.8.exe' has exited with code -1 (0xffffffff).)
If I DO check 'Enable Native Code Debugging', the programme ignores my Python breakpoints, and pops up this window:
If I choose 'Close' then Visual Studio starts to run the Python script (without hitting any Python script breakpoints), the assertion is hit, and choosing 'Retry' opens my C++ code at the offending line (which is at least helpful up to a point). The same COM dll works fine if driven from VBA in Excel, so I suspect I have an issue with parameter passing via win32com.client, so I want to check if the dll is receiving what I think I am sending: hence the requirement to debug.
If I do 'Open the Symbols Settings Dialog', I get this:
Where you can see that I have followed the MS instructions on their website, and used the Python 3.8 installer to install the symbols. The directory C:\Program Files\Python38 does indeed contain python38.pdb. I suspect Visual Studio is loading python from somewhere else? Have I installed the symbols in the wrong place?
I would like to be able to step through my Python code (hitting breakpoints where marked), and also hit breakpoints in the C++ code. Is this possible, and if so, how do I set up my Visual Studio to play nicely with Python 3.8?
If anyone did wade all the way through the question, the solution that worked for me was to:
Heed the MSVC warnings that debugging Python 3.8 is not supported
Uninstall / Re-install Python 3.7 from python.org for all users (so to C:\Program Files\Python37), specifying that I wanted the symbols (custom install)
Ensure PYTHONPATH was set to C:\Program Files\Python37
In Visual Studio change the global default environment to Python 3.7
Add C:\Program Files\Python37 to the symbol search path (Debug Options)
Re-add all the packages that I needed to the 3.7 environment
When I run a python script now from VS, I can see that the command window has C:\Program Files\Python37\python37.exe
Checking 'Enable Native Code Debugging' now not only hits my Python breakpoints, but also any breakpoints in my C++ (when the file is open).
One fly in the ointment is that the Debugger spends a long time loading symbols for all of the individual python packages. I have tried specifying that I only want symbols for my COM dll, but to no avail. I start the Debugger and then surf SO looking at Q&A until I hit the first breakpoint some time later ...
If anyone has a fix for this, I'd love to hear it.
I want to be able to step through C++ code that is part of a dll used by a Python script.
I have looked at https://learn.microsoft.com/en-us/visualstudio/python/debugging-mixed-mode-c-cpp-python-in-visual-studio?view=vs-2019 and I think I've implemented this correctly. However when ever I enable Enable Native code debugging the breakpoints in Python are no longer functioning and it states that no symbols are found in code.
I went to the Visual Studio Python installation and have selected Python native development tools
And the Python symbols have been installed and are present in the active environment:
On the debug tab I have tried setting the interpreter path to python_d.exe and in Debug>Options on the Symbols tab I've selected the associated symbols:
I have tried selecting multiple options in the image above with no success.
I suspect it is something simple that I'm doing wrong, any ideas? Thanks!
I faced the same problem and didn't find a solution.
If you want a workaround, try to attach your native code to the python.exe process:
Start the debugging of your python script (without native support) and wait on some breakpoint
Launch your native project in another VisualStudio instance, set needed breakpoint and then go to Debug -> Attach to process, select started python.exe process (you can find it by PID)
Continue python execution.
It worked for me. Note that you need your native code to be compiled with debug symbols as well.
Happy bug-hunting! =)
When debugging my c++ code, I would like, when a I hit a breakpoint, to open an interactive python window (similar to "Evaluate Expression" in pycharm) and run a visualization/inspection script on variables in memory. I s there an extension for VS2019 that enables it?
I'm currently trying to debug issues in Caffe for Windows PyCaffe.
Because of a bug in Python Tools for Visual Studio, PTVS doesn't work so I'm using PyCharm and trying to attach to PyCaffe's process through Visual Studio 2013. That is, I'm running PyCharm debugger on a Python script with a breakpoint set at the point where I call the Python entry point into PyCaffe.
I debug the Python script in PyCharm which calls modules written in C++ in VS. I want to debug those modules in C++. So I'm trying to attach to the PyCharm or Python processes with breakpoints set in VS.
The problem is that the breakpoint isn't firing at the entry point in PyCaffe in the Visual Studio C++ code.
Has anyone successfully gotten this kind of thing to work or is there an alternative way of doing this?
I faced a similar problem a few years ago, trying to
debug a user-mode driver wish was loading automatically from a RPC, the solution I found was:
Download Debugging Tool for Windows (depending on your system x86 or x64), wish is free,from the Microsoft Download.
Add "__asm int 3"(this is asm instruction for a hardware breakpoint) in the place on the C code where you whant to the break point to take effect.
Compile the C program, nomally with debug info (this part is important,because help the Debugger to find the source file), this should not make any problems.
Attach the Debugger to the running process (in my case was the explorer process), in your case should be the process that make first call to the library, for example if PyCharm create a process for the new python code, the debugger need to be attached to that process(you can manage this by setting a breakpoint in python, wish will give you time for doing the attach process), the easy way for me to figure this out was to let the process crash, because "__asm int 3" cause a process crash if a debugger is not attach, you can take advantage of this waiting for the crash and when windows shows you the screen "Process ... has detected a problem an need to be closed", you know who is the process that you are looking for.
This could be painful the first time but for me quite effective, because you
can see the data flow from one program to another,
We attach to one process and allow to set breakpoints within code that has not started from the VS debugger. But one important issue is that we often debug/run the app in the VS, for example, we debug the Web code that runs under IIS, we will attach to the IIS process or others.
Your project is different from the above sample, you run/debug your app in Pycharm (not the VS), but you want use the VS Attach to process function, so it would have a limitation. As you said that you debug script in PyCharm, and want to call C++, so you would check that whether the PyCharm supports a similar feature like the attach tool in VS.
I'm trying to debug a c-code dynamic library written via Xcode (7-beta), and the library is wrapped as a Python (2.7.3) module. Swig (v3.0.5 --> http://www.swig.org/) is being used to do the bindings and Xcode to compile and generate the library. It's all running fine. Python is running via PyCharm (CE 4.5.3).
In order to debug the library, I do a debug build, start the module from PyCharm, go to Xcode, menu "debug->attach to process->Python" attach to the process and it works like a charm, programmer's dream (almost). The breakpoints are reached, variables read, etc.
So here's the problem:
While the C code is correcly halted on a breakpoint, the running script in PyCharm is finished (with exit code 0), as if it had naturally reached it's endpoint. Here's a simple situation where the problem is reproduced:
C-code (the dynamic library):
int TestIt(){
return 42;
}
While the Python code is basically:
import time
import my_c_dinamiclib
for i in range(60):
print i, my_c_dynamiclib.TestIt()
time.sleep(1)
So there are 60 seconds to attach to the process.
Does anyone know how to deal with this? I've tried running Python in debug mode, with no success.