Has anyone got hardware breakpoints to work on 64bit XP and if so how?
We have an application that uses hardware breakpoints this has worked on 32 bit XP and 32 bit Vista operating systems for sometime now. However having ported our code to 64 bit we get a crash when the app is run on 64 bit XP but not when run on 64 bit Vista. The app is compiled and built on XP.
We have isolated this down to thread resumption after setting a breakpoint (DR7=1). The crash occurs if we raise a file dialog box and the GUI controls on forms are rather flaky. Strangely, if after setting the breakpoint and observe the flaky GUI, we then disable the breakpoint (DR7=0) the GUI starts behaving normally again and raising the file dialog does not cause a crash.
We have replaced our breakpoint setting code with other example breakpoint setting code and each example has the same problem.
Has anyone got hardware breakpoints to work on 64bit XP and if so how?
I guess that's a no then!
You can create a simple MFC application in Visual Studio and set a hardware breakpoint, e.g. a data breakpoint, in the debugger and the application will demonstrate the same behaviour as you're describing.
XP x64 does seem to be messed up sometimes when compared with the Vista/7 codebase. Therefore, it probably comes as no surprise that Microsoft aren't supporting XP x64 at all for some of its newer products, including Office 2010.
There is an interesting project on Codeproject : "Toggle hardware data/read/execute breakpoints programmatically"
Visual Studio has Data Breakpoints. You can set the debugger to stop on write to a specific memory address.
http://msdn.microsoft.com/en-us/library/350dyxd0.aspx
Related
I am working on a plug-in for an application. I have old development tools that have problems. My development tools are all from old 32 bit versions. CodeWarrior 6.7.and 8. I am running windows 7 pro 64 bit and having problems with the old tools. The CodeWarrior debugger will only work one time and I have to reboot before it will work again. It also has some problem using it. Break points stop working.
I switched to UeStudio from IDM but can not get a debugger to work. I created a project to use the compilers from Microsoft Visual Studio 10.0. UeStudio is supposed to use an integrated debugger. It downloads WinDbg.exe but it wont start up. The only WinDbg I found on Microsoft is from the Debugging Tools for Windows (x86) and (x64). It does not integrate with UeStudio. It starts up in a separate window. I have played around with it a bit but can not get it to load my DLL. I keep getting and error that it can not load my symbols (mismatching symbol file). I have set it to look were the '.pdb' for my plugin is located an doubled checked that it is correct. It's message names my DLL. I do not have symbols for the application. They do not supply one. I can load my source file and set Break points. But can not examine data.
Anybody get UeStudio debugging to work on windows 7? Or have any idea on debugging DLL on windows 7 cheaply.
I use OllyDebug.
OllyDbg
IDA is also very nice (paid)
Original app was developed with VS6 MFC for WinXP - then ported to VS 2005 Vista, and runs fine in Vista. However, when installed in Win7 the app runs without crashing but the UI is scrambled. Windows controls all seem to line up on left edge of main window.
Can this app created with VS2005 in Vista run properly in Win7? Or does it need to be compiled and linked in Win7 to run properly in Win7?
The most likely explanation is that your program has bugs in it, or rather it makes assumptions about Windows that aren't valid: a correctly written program built on an old system with an old version of Visual Studio will work fine on Windows 7. As ever, just because something worked on old versions of Windows doesn't prove it's "right".
There aren't any easy shortcuts for this: you're going to have to debug your application to figure out what is wrong with it.
On my development machine I am running IIS7 on Windows 7 64 bit and enabled "Enable 32-bit Applications" so i could use Ionic rewrite module. The problem is that under this configuration even though I attach to the right process my breakpoints will not get hit. Taking a closer look at the "Attach to Process" dialog I noticed that all other processes where running under x64 except the w3wp.exe that i am trying to debug. I reverted the "Enable 32-bit Applications" setting back to false and then my breakpoints work but my rewrite engine blows chucks because i am now in 64 bit mode. Does anyone have any ideas how to go about solving this issue.
With a little help from a friend i found that ionic rewrite did have a 64 bit download. Installed and works fine now.
So I've been developing on Windows XP Visual Studio 2008. I guess it is building my C++ app in 32 bit mode. When I run the program on my new Windows 7 64 bit box, it gets half way through loading a then throws an access violation error. So, I loaded all my development tool and recompiled the project on Windows 7 to find the crash site but it works perfectly! What? How do I make my app work on x64? Do I have to release two seperate versions? I know I can target 64 bit but I don't like two separate executables. I've searched but keep getting the two version solution or everything .net. This is a native C++. is there an x86 flag somewhere?
"Do I have to release two seperate versions?"
It depends on what your app does. The majority of 32bit apps work just fine in WoW mode.
"is there an x86 flag somewhere?"
Yup. Open up the configuration manager (Alt-B, O) and you will likely see a win32 in the platform selection.
Why your app crashes is going to take some debugging. You should be able to attach the debugger to the 32bit version on the 64bit OS.
Have you considered the possibility that you may be trashing memory? From the way that the application happens to be loaded into memory, it may be that the 32-bit app on 32-bit Windows and the 64-bit app on 64-bit Windows "get lucky", i.e. no important memory locations are overwritten, whereas the 32-bit app on 64-bit Windows is less lucky and crashes.
To find out if you are indeed trashing memory, you can use tools such as Purify and Valgrind.
As the others' answers already said, it is very likely that the application has bugs that are being hidden in one environment. A good tool that has a low cost of entry in terms of learning curve is Microsoft's application verifier. That along with the debugging tools can provide a very good start. Take a look at the gflags utility.
Can someone tell me why I don't have all of the dev studio windows available to me when I develop on a 64-bit platform? I upgraded my dev desktop box to server 2003 x64 to match our deployment platform. Since then (I'm using VS2005) I've noticed that several windows aren't available. I can't view Processes (which is the most annoying) so I don't know which processes I'm attached to. I can attach to a process fine, but it won't show me what is already running under the debugger. There are others, but that's the one that sticks out in my mind at the moment.
My question is where are these limitations of developing under 64 bit documented (assuming they are)? (Of course, I also get the "Edit/Continue" warning dialog all the time telling me that doesn't work in 64-bit)
Also, is VS2008 any better under 64 bit?
Follow-up: Apparently my question is a little bit vague. I'm developing a 64-bit app on a 64-bit development environment. "Recompile it in x86" doesn't solve my problems.
Follow-up #2: I'm giving it one more shot. I WANT TO DEBUG A 64 BIT PROGRAM ON A 64 BIT ENVIRONMENT AND I DON'T HAVE ALL OF THE VISUAL STUDIO FEATURES SHOWING UP. HOW DO I GET THEM?
Follow-up #3: I just installed XP 64 (previously I was using Server 2003 64-bit) and those features all showed up again (Process window, etc). Apparently the server version of windows doesn't provide all of the dev features.
Can anyone tell me why?
"Edit/Continue" can work if you change the build setting to X86 :)
Here was the suggestion from StackOverflow about it.
I had some problem with NUNIT when debugging code. The solution was to use the special program in the \bin\ folder Nunit-x86.exe for old code built in x86 and use the Nunit.exe for x64 built.