weird call stack problem w/VC 6...
-
Hi, folks! I develop test & measurement systems for our manufacturing operation. One of my systems' updates has introduced a very reliable crash and I'm having some difficulty tracking down the problem. I have a desktop PC set up the same way as my testers (w/o the hardware). When I run the app in debug mode there I can trace the program flow through the call stack window (I'm using the VC 6 IDE as my debugger). However, when I try the same thing on real hardware the CS window is blank (even if I set a break at WinMain). Also, if I try to use the step out of function button, the status bar displays a message saying the function has no return address (yet stepping through it returns just fine!). Any clues as to how I can solve this? Both locations read the same project (dsw and dsp) files, so the settings should be the same, right? Here are links to window snapshots showing the debugger in action. The first image is running on the desktop system, showing the proper view of the call stack. The second image is running on the test system. Note the absence of any info in the call stack window. The last image is also on the hardware, but using Wndbg. Note that the call stack seems to be ok. Desktop View Hardware View Hardware View using WnDbg TIA!
'til next we type... HAVE FUN!! -- Jesse
-
Hi, folks! I develop test & measurement systems for our manufacturing operation. One of my systems' updates has introduced a very reliable crash and I'm having some difficulty tracking down the problem. I have a desktop PC set up the same way as my testers (w/o the hardware). When I run the app in debug mode there I can trace the program flow through the call stack window (I'm using the VC 6 IDE as my debugger). However, when I try the same thing on real hardware the CS window is blank (even if I set a break at WinMain). Also, if I try to use the step out of function button, the status bar displays a message saying the function has no return address (yet stepping through it returns just fine!). Any clues as to how I can solve this? Both locations read the same project (dsw and dsp) files, so the settings should be the same, right? Here are links to window snapshots showing the debugger in action. The first image is running on the desktop system, showing the proper view of the call stack. The second image is running on the test system. Note the absence of any info in the call stack window. The last image is also on the hardware, but using Wndbg. Note that the call stack seems to be ok. Desktop View Hardware View Hardware View using WnDbg TIA!
'til next we type... HAVE FUN!! -- Jesse
Hi Jesse, Have you tried setting up a symbol server to see if that improves things ? A little self promotion, but only because I am trying to help... Setting up a symbol server Also, I assume you have copied the .pdb file to the 'real hardware' machine ? regards,
Jonathan Wilkes Darka [Xanya.net]
-
Hi, folks! I develop test & measurement systems for our manufacturing operation. One of my systems' updates has introduced a very reliable crash and I'm having some difficulty tracking down the problem. I have a desktop PC set up the same way as my testers (w/o the hardware). When I run the app in debug mode there I can trace the program flow through the call stack window (I'm using the VC 6 IDE as my debugger). However, when I try the same thing on real hardware the CS window is blank (even if I set a break at WinMain). Also, if I try to use the step out of function button, the status bar displays a message saying the function has no return address (yet stepping through it returns just fine!). Any clues as to how I can solve this? Both locations read the same project (dsw and dsp) files, so the settings should be the same, right? Here are links to window snapshots showing the debugger in action. The first image is running on the desktop system, showing the proper view of the call stack. The second image is running on the test system. Note the absence of any info in the call stack window. The last image is also on the hardware, but using Wndbg. Note that the call stack seems to be ok. Desktop View Hardware View Hardware View using WnDbg TIA!
'til next we type... HAVE FUN!! -- Jesse
I'd check and make sure your dev and test environments are the same. Make sure that all of the dlls, etc that you app depends on are the same version in both environments. Here's a similar case to yours. http://groups.google.com/group/microsoft.public.vstudio.development/browse_thread/thread/4ab576781d9b05b8/14be7f83d8ef39af?lnk=st&q=no+call+stack+displayed&rnum=3#14be7f83d8ef39af[^]
-
I'd check and make sure your dev and test environments are the same. Make sure that all of the dlls, etc that you app depends on are the same version in both environments. Here's a similar case to yours. http://groups.google.com/group/microsoft.public.vstudio.development/browse_thread/thread/4ab576781d9b05b8/14be7f83d8ef39af?lnk=st&q=no+call+stack+displayed&rnum=3#14be7f83d8ef39af[^]
Thanks for the link. That certainly sounds like my problem; I'll have a look into it. Again, thanks!
'til next we type... HAVE FUN!! -- Jesse
-
I'd check and make sure your dev and test environments are the same. Make sure that all of the dlls, etc that you app depends on are the same version in both environments. Here's a similar case to yours. http://groups.google.com/group/microsoft.public.vstudio.development/browse_thread/thread/4ab576781d9b05b8/14be7f83d8ef39af?lnk=st&q=no+call+stack+displayed&rnum=3#14be7f83d8ef39af[^]
cgreathouse, That was it! Thank you very much. Turned out that the imagehlp.dll on the system that worked was v 4.00. The version on the failing system was 5.00.2128.1. I replaced it with the v 4.00 and now I get a call stack. Have a beer on me!
'til next we type... HAVE FUN!! -- Jesse