21

I used to be able to attach to my w3wp process and Debug my web application, but this is not working anymore. I have no idea what changed to break this. I'm using Visual Studio 2008 SP1. And I'm debugging in IIS, not using ASP.NET's own server (i.e. I don't Run my project, I simply attach to a running process (w3wp).

My breakpoints simply have the "breakpoint will currently not be hit. The source code is different from the original version."

What I have tried:

  • Did a solution Clean.
  • Did a solution Rebuild.
  • Made sure that compilation debug=true in my web.config file.
  • Deleted the bin folder
  • Restarted Visual Studio
  • Restarted IIS
  • Restarted my Computer
  • Added a simple Response.Write to ensure that the latest DLL is being used. It is.
  • Made sure that Debug ASP.NET is checked in my project properties. It is.
  • Made sure that all my projects are compiled in my build configuration. They are.

But none of these help. I attach to w3wp, but my breakpoints never get hit.

Any ideas?

willem
  • 25,977
  • 22
  • 75
  • 115
  • I assume you're debugging in IIS and not using the built in asp.net server in Visual Studio? Also, VS version pls. –  Mar 15 '10 at 11:53
  • I'm using VS2008 SP1, and yes I'm debugging IIS. (clarified in the question also). – willem Mar 15 '10 at 12:02

16 Answers16

11

I had this problem recently and I ended up first making sure Visual Studio was not running at all on the system.

Then went into this folder and deleted all its content:

C:\windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\
Gautam
  • 2,065
  • 1
  • 24
  • 24
8

Check your web.config for

<compilation debug="true">...
citronas
  • 19,035
  • 27
  • 96
  • 164
3

When you "Attach to process", the Output window should show you (when showing output from "Debug") all the libraries it's loading, and where it's loading them from - for the dll's in your /bin folder these are usually copied to the \Temporary ASP.NET Files\root\ folder - where are yours being read from? Have you definitely cleared them out from there?

The only other things I can think of:

  1. You've compiled your code in "Release" mode rather than "Debug" (not the web.config) from the Solution Configuration drop-down.
  2. The symbol files (.pdb) are missing from your /bin folder.

On the "Build" tab of the project properties, you are in configuration "Active (Debug)", you haven't check "optimize code"?

If you click "Advanced..." on that tab, what value do you have for "Debug Info"? Is it "full" or "none"?

Responding to comment

You will find it harder to debug successfully if your code compiled in "Release" mode, and you'll often get the "source code is different" message when you've not rebuilt the symbols (.pdb files) after changes - but you say you've done a clean/rebuild, so that should cover that.

Yes, your output window will show all the framework dlls that you're referencing as well as your code - but you should see one file listed in there with the name of each project output - those are the ones to look at.

You don't have some post build event that moves files into the correct directory for your site do you that's silently failing?

Zhaph - Ben Duguid
  • 26,785
  • 5
  • 80
  • 117
  • Thanks, definitely some good things to consider :) I have compiled my code in Release mode. My symbol files are in my \bin folder. "Optimize Code" is Not checked. Debug Info is "Full". The only remaining confusing thing is which files are supposed to show up in my "Debug Output" window. Lots of files there :/ – willem Mar 15 '10 at 13:03
  • Nope, no post build events. I'm really stumped :/ – willem Mar 15 '10 at 13:37
  • Are you able to debug successfully when you compile in "Debug" mode? – Zhaph - Ben Duguid Mar 15 '10 at 13:58
  • Ok, only your original comment said "I have compiled my code in Release mode". – Zhaph - Ben Duguid Mar 16 '10 at 07:26
  • @Zhaph-BenDuguid For me I didnt see my dll in \Temporary ASP.NET Files location. Is there any thing I have to do? – Linoy Aug 04 '17 at 06:46
3

I also had this problem, solved it by changing the "Attach to" code type to Automatic on the "Attach To Process" dialog. (Previously I had this set to "Silverlight Code" due to debugging a different process... it can be easy to forget to change this back.)

Mr. Bungle
  • 1,696
  • 17
  • 21
  • 1
    God I was going out of my mind because of this. Thank you kindly sir! I was debugging native code before that and this property never changes if you don't do it manually – cah1r Apr 28 '16 at 09:56
  • You can also run into that variant of the issue when the managed module isn't loaded yet as you attach. Then the automatic debug type is set to native. Once the managed module is loaded, because the debug mode was set to native the symbols loading is skipped. You can also detach and attach again. As the managed module is now loaded, the automatic debug type selection will correct itself to mixed-mode managed. – David Burg Aug 04 '20 at 17:36
2

I know this issue has been open for some time, but I think it is the same as I experienced:

I could not debug my .aspx server side code. I had a working WepApp AnyCPU project and I wanted to link to some x86 dlls, so I created an x86 debug target. Did similar things, rebuilt, stopped the development web server, rebooted, clear temporary files, all to no avail.

Fixed the problem by changing the target folder to bin\ (was bin\x86\Debug).

Digital Chilli
  • 291
  • 2
  • 3
  • Same here, fixed the problem by changing the target folder to bin\, I was trying to debug a webservice. To see if your file were loaded correctly, use the modules window (VS Menu -> Debug -> Windows -> Modules), column Optimized needs to be 'No' for your projects. – Damian Vogel Jul 24 '14 at 09:16
1

Did you check your assembly.cs file with this attribute 

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.Default)]

After reflecting a optimized code you will probably get this. So you must remove this to be able to debug again.

HoKy22
  • 4,057
  • 8
  • 33
  • 54
Tümay Tuzcu
  • 11
  • 2
1

Are you running any add ins that could be affecting this? Or any tools that apply post build operations to the source code that the DLLs you start debugging with have been modified post build and it actually is correct that it's not the same source code so debugging won't work?

Also have tried resetting VS?

devenv.exe /resetsettings

Edit: if none of the information has aided you here, while painful it might be worth uninstalling and reinstalling VS and SP1. If you go through this and the issue is the same afterwards that atleast assures that the issue lies in either the web.config or the project settings.

Chris Marisic
  • 32,487
  • 24
  • 164
  • 258
1

I faced the same issue. The w3wp process took a lot of memory and did not want to be reset on web application publishing.

Press Ctrl+Alt+Delete > Go to "Processes" tab > find w3wp process and kill it. Run the app again (if this is an mvc app, just go to a related url to automatically recreate w3wp process).

Warnings will disappear after that.

Anton Lyhin
  • 1,925
  • 2
  • 28
  • 34
1

I have tried all the below options in my Visual Studio 2013 Update 4.

  1. Reset IIS
  2. Clean solution and rebuild
  3. Delete the friles from temporary folder C:\Windows\Microsoft.Net\Framework...\Temporary ASP.NET files
  4. Check whether the compilation tag is debug or not

But none of them worked, here I am listing down the two things which worked for me.

  1. Disabling the "Just My Code" option Tools ->Options -> Debugging -> General -> Uncheck Enable Just My Code.
  2. Edit the web.config file and save (You can always create a space in any line in web.config, that will do)

Please be noted that this solution can be Visual Studio version specific, and the both fix worked for me in my Visual Studio 2013 Update 4.

Sibeesh Venu
  • 18,755
  • 12
  • 103
  • 140
0

I have had this problem for a while and found my solution on the MS forum (link below). Debug Diagnostic Tool was the culprit for me, but I did not have to uninstall it. I had a crash rule set up for the w3wp process and I simply removed that rule and restarted everything.

Microsoft Forum for Unable to attach error

Pam
  • 1
0

in the "Attach to process" dialog, click the checkbox (near the bottom) for "show processes from all users" and if you see two w3wp.exe processes, try the other one.

One should have a comments/description value of something like T-SQL, managed somethingoranother. This is the one you want.

David Fox
  • 10,603
  • 9
  • 50
  • 80
  • Good tip. But I only have one w3wp (all my checkboxes are checked). And it's Type is "T-SQL, Managed, x86". – willem Mar 15 '10 at 11:46
0

On OpenVMS we just used to:

Compile/Debug then Link/Debug

and that was it! Simples!!

but seriously, make sure the file you have your Debugger.Break line in, has 'Copy always' set in its Properties before re-building

Reg Hammond
  • 1
0

I was using the Visual Studio extension VSCommands to attach the debugger (convenient). However, IIS Express was running, and I guessed it might be interfering. Sure enough, when I closed IIS Express, suddenly I was able to debug again.

Joy ensued.

Community
  • 1
  • 1
ErikE
  • 48,881
  • 23
  • 151
  • 196
0

In my case I had a Console Application the hosted web page in .Net Framework 4.6.1. When I added a Debug to Conditional compilation symbols, it started to work:

enter image description here

Mik
  • 3,998
  • 2
  • 26
  • 16
0

Make sure that "Current Page" and not "Don't open a page. Wait for a request from an external application." is checked under Properties->Web->Start Action.

NegativeFeedbackLoop
  • 140
  • 1
  • 7
0

add this code in your .csproj file

   <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <Optimize>false</Optimize>
    <DebugType>full</DebugType>
    <DebugSymbols>true</DebugSymbols>
  </PropertyGroup>
Noureddine AMMAR
  • 26
  • 3