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.
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.
I am debugging a minidump file that is made when my application is starting. I am viewing the dump file in Visual Studio 2010. What are the "Modules" shown? Are they all loaded for specifically my application ? Or some are just generic, system wide modules ?
I am trying to determine if there are 3rd party modules/dlls that could be interfering with my application. I pointed out Sophos as an example in the dump. Could Sophos be intercepting disk write, or memory access and causing an issue with my application?
This is a commercial application that starts up fine, except for a few customer.
Thanks.
You are simply seeing the list of DLLs that were loaded in the process. The minidump is for a managed WPF application but you are also seeing all of the unmanaged DLLs. A minidump is fundamentally an unmanaged view of the process. You would get the same list if you debug your WPF app on your dev machine with the Project + Properties, Debug, "Enable unmanaged code debugging" option ticked.
And yes, that DLL you marked was injected by the Sophos anti-malware program. This is entirely normal, it is the way that they work. They absolutely do things like you suspect, mostly by hooking winapi functions, as the "detoured" name suggests. Detours is a Microsoft hooking library.
They are not automatically a simple explanation for a crash, although they certainly have a knack for destabilizing programs. Your program crashed with an access violation, you'll need to use the debugger to find out why. Not an easy kind of crash to diagnose btw. Good luck with it.
I got to decompile a VB6 dll, got a decompiler (actually tried 4 of them), even paid for a pro license, but of course I ran into a problem: the retrieved code doest even look like the previous one and it looks like a lot of information is lost. I do understand it's a one way road, but maybe someone could technically explain to me why VB6 compiled dll loses some info in machine code which cannot be retrieved later on in the decompilation process?
This is not possible to do unless the code was compiled with the option to compile to P-Code. For example, if you look at http://www.vb-decompiler.org/ it clearly says that it will only work with the P-Code.
The issue is that VB6 by default will compile to machine code which doesn't translate to VB6. You may be able to get the UI back because this is not code, but aside from that you are out of luck.
I am having to use a 3rd party ActiveX DLL in my VB6 application. However, now that I've included the DLL in the references and used it in code, every time I quit my app, it also quits VB6.
I don't see anything in the logs or event viewer that would suggest why this is happening.
Is there anyway to prevent this?
Btw, I have contacted the vendor, but they are focused on their .NET products, it seems.
You may not be using the component correctly by missing specific initialization or termination calls, which has the affect of bringing down VBIDE. This usually happens when the third-party component or your application make Win32 calls.
I have had a few applications that I ran them through the debugger, they always terminated VBIDE. Yet, running the Release or Debug versions normally, resulted in the applications working just fine.
Try switching DEP off for VB6.exe only or altogether.
Also, this might be a license checking issue i.e. registry permissions -- try running VB6 IDE as Administrator (right click->Run as Admin)
I'm not a VB6 programmer by trade. I just mess around with the stuff. I have heard of this scenario referred to as sub-classing. Run a search on pscode.com. They have code and tutorial examples about how to prevent it. Good luck.
Ouch. I feel your pain.
Can you switch to a .Net component, and use it from VB6 via interop? I.e. write a COM-visible wrapper in VB.Net?
Just to close this question out... After spending significant time trying various things I ended up writing code that unloaded the control, paused for 5 seconds and then quit app. That seemed to do the trick.
Im sure this has happened to folks before, something works in debug mode, you compile in release, and something breaks.
This happened to me while working on a Embedded XP environment, the best way i found to do it really was to write a log file to determine where it would go wrong.
What are your experiences/ discoveries trying to tackle an annoying Release-mode bug?
Make sure you have good debug symbols available (you can do this even with a release build, even on embedded devices). You should be able to get a stack trace and hopefully the values of some variables. A good knowledge of assembly language is probably also useful at this point.
My experience is that generally the bug is related to code that is near the area of breakage. That is to say, if you are seeing an issue arising in the function "LoadConfigInfoFromFile" then probably you should start by closely analysing that for issues, rather than "DrawControlsOnScreen", if you know what I mean. "Spooky action at a distance" type bugs do not tend to arise often (although when they do, they tend to be a major bear).
Tracefile is always a good idea.
When it's about crashes, I'm using adplus, which is part of debugging tools for windows. basically what adplus does, is, it attaches windbg to the executable you're monitoring. When the application crashes, you get a crash dump and a log file. You can load the crash dump in your preferred debugger and find out, which instruction lead to the crash.
As release builds are heavily optimized compared to debug builds, the way you compile your code affects its behaviour. This is basically true when crashes in multithreaded code happen in the release version but not the debug version. adplus and windbg helped me, to find out, where this happened.
ADPlus is explained here:
httx://support.microsoft.com/?scid=kb%3Ben-us%3B286350&x=15&y=12
Basically what you have to do is:
1. Download and install WinDbg into C:\debuggers
httx://www.microsoft.com/whdc/devtools/debugging/default.mspx
Start your application
open a cmd and cd to c:\debuggers
start adplus like this:
"adplus.bat -crash your_exe.exe"
reproduce the crash
analyze the crashdump in vs2005 or in windbg
If it's only a small portion of the application that needs debugging then you can change those source files only to be built without optimisations. Presumably you generate debug info for all builds, and so this makes the application run mostly as it would in release, but allows you to debug the interesting parts properly.
How about using Trace statements. They are there for Release mode value checking.
Trace.WriteLine(myVar);
I agree on log file debugging to narrow it down.
I've used "Entering FunctionName" "Leaving FunctionName" until I can find what method it enters before the crash. Then I add more log messages re-compile and re-release.
Besides playing with turning off optimization and/or turning on debug information for your Release build as pauldoo said, a log file will good data can really help. I once wrote a "trace" app that would capture trace logs for the app if it was running when the release build started (otherwise the results would go to the debugger's output window if running under the debugger). I was able to have end-users email me log files from them reproducing the bugs they were seeing, and it was the only way I would have found the problem in at least one case.
Though it's probably not usable in an embedded environment, I've had good luck with WinDbg for debugging release-mode Windows applications. Even if the application is not compiled with symbol information, you can at least get a usable stack trace and plenty of other useful crash information.
You could also copy your debug symbols to the production environment even if it's compiled in relase mode
Here's an article with more information
If you problem is synchronization related dumping log in the file might be problematic.
In this case i usually will use some big array of string and dump this to screen/file after the problem was reproduces.
This is of course depend on your memory restriction, sometime i use just few symbols and numbers to store in the array if the memory on the platform is limited. Reading such logs is not a big pleasure, but sometimes this is the only choice.