In Visual Studio 6, I have written an ATL COM server EXE. I want to debug this and put a breakpoint at the start of the method I am calling. I start debug and then call the method from the other EXE but the breakpoint is never hit. This was working fine a couple of weeks ago. I could break into it no problem. I can't work out what has changed that this is no longer working. Can anyone help?
Your exe or pdb probably don't match the source. Try rebuilding the project, and make sure the executables you've just built are used by the server.
FWIW, you can also place a call to DebugBreak in your code. If the source and executables indeed don't match, the debugger will let you know when it breaks.
Related
I'm using a 3rd party dll with no source code available. It runs perfectly fine, but every time I run my program, an annoying pop-up says "MyProgram.exe has triggered a breakpoint".
If I press continue, my program runs 100% correctly.
If I press break, I can see that the breakpoint is occurring in the 3rd party file alp41basic.dll
I have no clue why they put breakpoints in their dll. How can I disable them?
My question is identical to one that went unanswered:
https://stackoverflow.com/questions/17514072/is-there-a-way-to-make-visual-studio-continue-when-an-exception-occurs-on-a-line
I eventually checked in with the company that distributed the dll, and indeed there are breakpoints in there for reasons that I won't get into. However, if I run the program outside the debugger (even simply open the binary from windows), these popup windows do not occur.
Thank you all for your help!
I feel like this is a stupid question, but I can't seem to figure out the answer. I've currently got a C++ application that's loading & utilizing a DLL (I compiled both the application & the DLL with VS 2010). I'm positive it's using the DLL, because a) if I rename the DLL, I get a not found exception, and b) it's displaying output that only comes from (and I can change it to see the output change) inside the DLL.
My problem is that in Visual Studio's Modules window while debugging, the DLL does not appear to be loaded. Because of this, obviously its got no symbols and I can't set breakpoints... But this doesn't make any sense to me as it's clearly using the DLL.
I've seen several other similar questions, and the answer has generally been too look at whether the code is native, managed, or mixed, and set the "Attach to Process" field accordingly. I've tried all the options there, and made sure my Debugger Type is set to "Mixed" (though I've tried it with Native & Managed as well, just to verify none of these solve the issue).
Does anyone have any suggestions?
Thanks in advance!
This happened to me and I found the project->properties->Debug page and clicked the box to Enable native code debugging. I was doing a C# project accessing a C++ / native dll
budward
I have some ideas:
check output windows it the DLL symbols are missing.
Make sure dllname.pdb file exist beside the DLL
make sure visual studio solution has two projects (EXE,DLL) projects
switch to DEBUG mode instead of RELEASE mode.
run process explorer (download it from MS) and check the path of the DLL that is bonded to the EXE in runtime.
Finally the ultimate solution:
Open Process Explorer and search for your DLL name.
Find which EXE is using it.
Goto VS and attach your debugger to that EXE.
I hope any of those fix your issue
I am remotely debugging a dll (C++, unmanaged) for Microsoft FSX (I do not know whether this matters). The dll is compiled as "Multi-threaded-dll", since it does not work as "Multi-threaded-dll debug". My dll currently just contains a DllStart and DllStop function, this is standard in FSX.
I general debugging works (it stops at my breakpoints), but somehow the debugger also stops in places where I did not place a breakpoint. First the issue came up in the "NO Source available" flavor. After checking
Suppress "No Source Available" pane in 2010 and
No Source available
the only solution working for me was to install the mentioned extension. Now I do not get the "No source" tab anymore, but debugger still stops somewhere outside my code. I have cleaned all breakpoints as recommended in " Debugger stops when there is no breakpoint VS2010 ".
bglmanx.dll is another dll, also started by FSX. I was thinking, OK, maybe there is some ambiguity about the symbols and have renamed my functions to DllStartFSXM and DllStopFSXM (and hence being unique). No improvement.
Any ideas, hints?
It could be caused by having __asm int 3 or a DebugBreak in the other code?
Perhaps there is some way of disabling these commands or reimplmenting the DebugBreak function?
In C++, on this site: http://msdn.microsoft.com/en-au/visualc/bb985511.aspx
I downloaded the code sample and went to Debug and it came up with a messagebox with 2 textboxes in it and told me to specify the executable file to debug. So I did, and then I clicked browse, but there is NO executable because the stupid thing hasn't created one yet.
I'm using visual studio c++ 2008; what's up with that weird message?
This message generally comes up when you try to debug into a system DLL or 3rd party code. Set a breakpoint with F9 and hit F5 and see if stop in your code in debug. Also make sure you are building the debug version.
happy coding.
That project builds a DLL. If you're going to debug a DLL, you need to provide a .EXE that loads the DLL.
I have a native C Dll that calls 'LoadLibrary' to load another Dll that has the /clr flag turned on. I then use 'GetProcAddress' to get a function and call it on dynamically loaded dll. I would like to step into the dynamic library in the debugger, but the symbols never load. Any idea?
And I should have said I'm using Visual Studio 2008.
Update: Thanks to some tips below, I changed the project debugging to Mixed. It didn't work, but I think I know why. I am developing an addin to an existing application. The app I'm connecting to starts one exe then it starts another. So I have to use "Attach to process" to fire up the debugger. My guess is launching the debugger that way will default to "Auto". Is there a way to change the default behavior of VS to use "Mixed" debugging?
This is from VS2008, but if I remember correctly VS2005 was similar. In the native project's properties, under "Configuration Properties->Debugging" there is a "Debugger Type" which is set to "Auto" by default. You'll need to change it to "Mixed", because VS isn't smart enough to realize you need managed debugging
I've had mixed experiences with doing similar things like this in VisualStudio. You might consider using ProcMon to see where VisualStudio is looking for the PDB file. Alternatively, you might try using WinDbg. It seems to do better at loading symbols and if it doesn't, you can explicitly load them yourself. Using WinDbg involves riding a steep learning curve, but if you're burning time right now, isn't it worth it?
You can also run the exe on its own and from the source of the managed dll, attach to the process to debug it.
Modify the mixed-mode dll to throw a CLR exception where it enters the first code you're interested in debugging. This should give you an opportunity to launch the managed debugger.
In VS2005, there are per-project options to enable native and CLR debuggers separately. You might need to enable the CLR debugger for the native dll project from which you start the debugger.