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.
Related
I've got a web application that won't run in debugging mode in Visual Studio. Running on Windows 7 computer with IIS 7 installed.
I've seen the numerous articles on the internet about re-installing the .NET versions, but this has not solved it for me. The project still refuses to compile.
In the Event Log there are several entries when I've started the debug process:
With a corresponding entry above it:
As stated I have run the .NET registration aspnet_regiis -i for both v2, v4 both 32/64 version of the .NET to no avail.
The error seems to point to the ISAPI filters, which I have tried fiddling with and configuring without success:
I'm now at a loss as to what's causing the problem.
This message is saying you're loading the 32bit aspnet_isapi.dll in a 64 bit w3wp.exe process.
You can check the application pool "Advanced Settings" for your 64 vs 32bit settings and select the correct one:
This is interesting, as you mentioned you do registered 32 bit version but your screen shot shows only 64 bit there.
Check my IIS:
Have you checked the configuration manager? I'm wondering would it be possible it was set to compile for certain CPU only.
We are moving to an all-64-bit development environment. Unfortunately VS 2008 and, more importantly, its built-in web server, run in 32-bit mode. When debugging code that references 64-bit assemblies - Oracle.DataAccess, for example - we experience the dreaded System.BadImageFormatException.
Can anyone offer any strategies for debugging code with 64-bit dependencies in VS? I suppose we could use a 32-bit Oracle provider, but we would like to emulate the production environment as closely as possible.
I have a similar setup on 64 bit Vista where I have the web site deployed in IIS - this site has in been successfully run and debugged in both 32 and 64 bit.
The biggest problem I have found is working in a mixed environment where some members on the project team are still on 32 bit Windows (both XP and Vista).
This causes headaches with project references to Oracle.DataAccess which I have only managed to solve with bindingRedirect entries in the web.config file in order to point to the correct version of the assembly.
If you use IIS7 you can choose 32/64 bit mode. You will then have to have your projects kick up with IIS instead of cassini which takes a little bit of work, but I think it will solve the problem with Oracle at least. Honestly I don't know how that would all work when attaching at 32bit debugger to it.
We use VMware hosts to give each of our web site developers their own virtual web server. You can use full IIS (as #KevinWon suggested) and install a 64-bit version of the debugger on them. I don't know the specifics of what our guys do - I found this out over a coffee the other day.
Set up an local IIS on your computer and set it to run in 32bit mode
http://kb.parallels.com/en/2131
If you enable the Debuging mode you can work with it, just like you would with the integrated development server. But you don't have to mess with the 32/64bit assemblies
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
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.