I have had this problem on and off recently with a project I am working on in WPF & C#. The WPF uses an external DLL as an interface written in C++ so its always jumping between managed and unmanaged code (this may or may not be related).
I have found that placing breakpoints and stepping through, sometimes the debugger will just halt and not continue. This is not due to an assert or any other problem because hitting "break" will show the debug cursor at the same line. Just not continuing over it (it happens randomly, anywhere, anytime). This is really frustrating when debugging because the whole debug process has to start again from scratch.
Has anybody come across this and confirm this exists? If so, does anybody have a work around?
Related
I am writing a JNI program, but I am having problems with the program and the data is not as expected. Java programs are launched in the IDEA environment. As the program keeps running, when the code executes to a breakpoint, this breakpoint is where java calls the dynamic library. I want visual studio to take over the program so that I can debug and observe the data.
I use google to search for a solution, I don't see the corresponding graphic tutorial, I am not sure if this solution is feasible.
If you can debug, any code can
If you can, I hope that you can provide a graphic tutorial, or suggest some steps, thank you very much.
After starting you Java application in IDEA and stopping at the breakpoint in Java code you need to attach the Visual Studio debugger to the running java process. The general approach is described here.
You should pay close attention to attach to the correct java process since there are usually several of them (including IDEA's). You can distinguish them by ID which is actually not that easy to find out in IDEA, but I think you can do it directly from your Java code as described here.
After successfully attaching to your process you can set up whatever breakpoints you need in your native code and then resume the application in both IDEs.
We have started encountering endless loops in our engine recently and I have no idea how to effectively fight them. The app simply freezes for eternity and I am unable to stop it's execution to understand what is going on. Placing normal breakpoint in major places (update loop) does nothing. I am almost certain that the problem is in a continuously running loop somwhere, but due to the code's size I cannot even start guessing where to look for it.
So, my question is how do you break app's execution in Visual Studio at some arbitrary place in the code, where the app happens to be at that time? Something akin to "stay where you are". Is it even theoretically possible?
Sure, use Debug + Break All.
This of course doesn't necessarily break your program at a nice address that happens to match one of the statements in your program. Pretty likely if setting breakpoints didn't invoke a break. You are likely to see a notification from the debugger that it cannot display source code. Or for that matter, it might not have selected the correct thread.
So first thing you want to do is use Debug + Windows + Threads and make sure that the correct thread is selected. Double-click the one you want to debug. Next thing you want to do is look at the Debug + WIndows + Call Stack window. It should at least display some of your methods, giving you a hint how it ended up in never-never land.
And it isn't unlikely that it got deadlocked on native code or an operating system call. To see that, you'll need to enable unmanaged debugging. Project + Properties, Debugging, tick the "Enable native code debugging". And make sure you've got the symbol server enabled so you'll get debugging info for the operating system DLLs. Tools + Options, Debugging, Symbols.
Good Morning,
I wanted to know if there is any program that can identify which component is causing a run-time error 430. I know enough to debug using VB6 IDE however its a strange case since the error does not occur when in the IDE. I have checked the references and components but they're all intact. So I'm looking for any debugging program that can attached itself to a compiled program and give me an idea of what .DLL component or .OCX component is causing the error more information.
Thanks in advance,
Jorgen
UPDATE: I have read all your responses thanks for all the help. Besides from spy++ and Process Monitor I was considering using OllyDbg it has a view called "Executable Modules" that basically show which DLLs are being called. However when I run my program in it, it freezes and doesn't continue loading the GUI. Anyone familiar with OllyDbg and know why this is occurring?
Thanks
Jorgen
Assuming you have all the source code, you can compile your VB6 EXE and the DLLs and OCXs into native code including symbolic debug info so that the PDB files are created (tick the checkbox on the Project > Properties > Compile tab). Then you can either use WindDbg or Visual Studio .NET to trace the problem.
WinDbg (http://msdn.microsoft.com/en-us/windows/hardware/hh852365) Please see the following:
"A word for WinDbg" by Mike Taulty (http://mtaulty.com/communityserver/blogs/mike_taultys_blog/archive/2004/08/03/4656.aspx)
"Old school debugging - VB6 middleware applications" by Mark Long (http://blogs.msdn.com/b/marklon/archive/2006/01/28/518616.aspx)
or
Visual Studio 2008 C++ Express or Professional with your PDBs.
Both ways need to have the source code in exactly the same path on the debug machine as on the build machine. The easiest way then, is to build and debug on the same machine.
It's probably easier to add logging to the application.
It is possible to debug without using the VB6 IDE, but its not easy - I recommend logging.
Logging is good and fine but it can be fustrating experience throwing logging all over the place before you have an idea where to start.
spy ++ is the stuff I use when debugging old vb code along with PView will give me a rough idea where the code is failing. And then add logging to those areas.
And check Hans Passands comment. It might save you some greef.
You can download "Process Monitor" from sysinternals: www.sysinternals.com, set the filters to not appear useless information and investigate for unsuccessful results, quite painful work but with good chances.
Quite often I use debugger to step into unknown and discover 3rdparty objects. VS debugger does great job of displaying the internals of anything. The problem here is when I hit a breakpoint I'd like to "snapshot" a variable with all those members debugger shows as a tree, stop debugging and continue writing code looking at the snapshot. Is that possible?
At the moment, I’m writing a small console program. It is small enough that I have not bothered to use an IDE, so I’m just using Notepad2 and cl.exe to edit and build the program, and the command-prompt to run and test it.
This works just fine for the most part (don’t freak out, but I’m actually using a bit of “printf debugging” here and there). Unfortunately certain problems are not quite as easy to fix. For example, a pointer/array problem can cause the program to crash.
I know about—and have—Visual Studio, Ollydbg, Windbg, etc. but those are all fancy, schmancy graphical IDEs and debuggers that are too cumbersome to fire up for what usually amounts to a five-second check before going back to the editor. My edit-compile-test cycle is often as low as 10-15 seconds, so such debuggers become an unacceptable bottleneck.
I’m trying to find out if there is a fast and easy method to debug a console application from the command-prompt. Is there a modern text-mode debugger? (Obviously debug isn’t going to be of much use.) Is there some other way—TSR‽—to view values, catch exceptions, or set breakpoints and step through a program?
You need ntsd (part of the same package as WinDbg, shares all comands) - http://msdn.microsoft.com/en-us/windows/hardware/gg463009
Also using free Visual Studio Express may make search for debugging advices easier...