Now and then I run into the following problem:

I start debugging the Add-In and breakpoints are ignored. Almost seems like the communication between the IDE and the component is not working.

My problem is that the last time this had happened I resolved it and now I can't remember what I did to fix it.

The breakpoint will not currently be hit. No symbols have been loaded for the document. enter image description here

Partly, the issue I am having is already described here but there is no solution for the actual breakpoint malfunction.

Please note that this normally works.

Deleting the bin and the obj does not seem to work.

This time I just restored my entire project from backup and started over but I would like to know how to fix this should I come across this again.

  • 1
    Is the "onDemand" xml attribute set to false in your config file? Aug 15, 2011 at 19:32
  • I don't have a definitive answer (though it usually means that the debugger can't find the pdb file for the loaded dll), but you can try sifting through these questions on SO to see if they move you in the right direction. Aug 15, 2011 at 19:33
  • @Kirk, I see no such attribute in the config.esriaddinx file. Aug 15, 2011 at 20:00
  • @Michael - thanks. will take a closer look. The problem is that i can be adding functionality to my add-in for months and happily debuggin away and sudenly breakpoints don't work... Aug 15, 2011 at 20:01
  • 2
    I've had it happen several times for no apparent reason, too. If I recall, deleting the obj and bin directories resolved it a couple of times, copying the suspect pdb and dll to the bin directory of the current project worked a couple of times, etc. Nothing I can point to that will work every time, though. Good luck. Aug 15, 2011 at 20:10

21 Answers 21


Here is an unofficial and still untested solution from ESRI staff. (They did stress that this is not an official solution)

Try removing from arcmap.exe.config, in the bin directory.

This is the \ArcGIS\Desktop10.0\bin\arcmap.exe.config xml file.

enter image description here

  • 3
    Actually, it is "documented" here resources.arcgis.com/en/help/arcobjects-net/conceptualhelp/… I ran into this problem while coding the ogr-workspace plugin and ended up putting it in the Developer FAQ github.com/RBURHUM/arcgis-ogr Oct 26, 2012 at 22:09
  • This solved the issue for me as well as another issue I was having of my Debug.WriteLine() messages not being sent to the output window in VS 2010.
    – GeoSharp
    Apr 4, 2014 at 1:41
  • I ran into this issue AGAIN and this is what worked this time. I am running VS 2010 Express (C#) and targeting .NET 4.0. I had to uncomment the v4.0 supported runtime version and remove the v2.0 reference.
    – Radar
    Apr 27, 2015 at 18:53

2 years and 2 version later and this is still a problem. Just finished updating/improving all my addins for 10.2 and came across this problem again. Implemented ALL sugestions in this post and nothing worked but I have discovered 1 additional possible problem. Unfortunately, I am not sure if this was the culprit or not because I've also implemented most other possible fixes at the same time.

New find: I realized i've been developing Addins since version 10 on the same machine and after re-installing have not always cleaned up legacy ArcGIS data. I found I had an older version of the culprit addin in a previous version of ArcGIS data in C:\Program Files (x86)\ArcGIS. Since ArcGIS will load the legacy addins there was possibly of some sort of a conflict. I removed all legacy arcgis application data (Desktop10.0, Desktop10.1) leaving only Desktop10.2 and the breakpoint came to life. Again I am not 100% if this is the solution but it may be another item on the list to check for.

I've seen this particular problem being called "the ultimate productivity killer" on another site and I could not agree more.

To sum up here is my current to-do list for the 'dead' breakpoint issue:

  1. Ensure, I am actually running the addin. Having debugger launch the application is not enough - the breakpoint will appear "dead" until I run the addin (button, menu option, etc.)

  2. Delete OBJ and BIN foders from the project directory.

  3. Delete the contents of assebmly chache: C:\Users\User\AppData\Local\ESRI\Desktop10.2\AssemblyCache

  4. Delete all legacy assembly data. (If current version is 10.2 delete Desktop10.0, Desktop10.1 asembly data) There is no proof that this helps or is a part of the problem but there is not reason this data needs to exist so I delete it just in case (C:\Users\User\AppData\Local\ESRI)

  5. As per ESRI's support suggestion; Alter the ArcCatalog and ArcMap config XML (didn't work by itself when I tried but several people have recomended this as a solution, including ESRI support) Locate ArcCatalog.exe.config and ArcMap.exe.config in C:\Program Files (x86)\ArcGIS\Desktop10.2\bin Open each xml in notepad and remove the line <supportedRuntime version="v2.0.50727"/> It’s about the fifth line

  6. Delete all legacy ArcGIS application data from the installation directory. This what worked for me. (probably) Go to: C:\Program Files (x86)\ArcGIS Delete all but current folders for Desktop10.x (i.e. Desktop10.0, Desktop10.1) Only the current Desktop version should remain in this location.

  7. Remove and re-add all project references including non-ESRI references, resave, repeat steps 2 and 3, recompile, run dbugger.

  8. Reboot computer. (This soetimes worked in the past) ALso found this being one of recomended solutions on Stack Overflow.

  9. In Config.esriaddinx - change the button to include onDemand=false: (Kirk's suggestion - see above) This didn't work for me personally.

  10. Rebuild project from scratch. (This worked for me in the past.)

  • Jakub, I had a similar but unrelated problem gis.stackexchange.com/questions/155016/… - it turns out legacy was an issue there too. The .net framework version wasn't current, so if you've tried all of those and it's still not working follow the link for yet another possibility. Jul 29, 2015 at 21:53

The only time I have gotten this is when I had another ArcMap instance open and forgot to close it before building/debugging. If you don't close all instances using the assembly then the old one will continue to be used. Or something like that.

  • I tried rebooting the computer opening VS and running the debugger without opening any other instances of ArcMap. It launched ArcMap as per usual bu the "dead breakpoint" problem persisted. Aug 16, 2011 at 0:15
  • so i just setup ArcGIS and Visual Studio on another machine (all clean install) and the same thing started happening again. I've tried everybody's suggestion and you seem to be correct. I made sure i kill all open ArcGIS processes and when I do so the breakpoints work. Sep 2, 2011 at 0:24

As my project's .NET Framework is 4.0, I changed to supportedRuntime version="v4.0.30319" in ArcMap.exe.config and I noticed that the problem was delayed by this change. I also remembered that ArcMap also loads ArcCatalog so I changed also ArcCatalog.exe.config to supportedRuntime version="v4.0.30319" and YES!!! It's working again. I spent all day trying to fix this and I hope it works for you too.

  • 1
    I had to delete also bin and obj folders. Oct 27, 2012 at 6:49

I tried the suggestions above for a while, and finally got to a solution. Cutting to the chase, I'll give the solution first, then the explanation:

  1. Open Task Manager. End Process for any copy of ArcMap.exe.

  2. Open a Windows Explorer. Navigate to C:\Users\\Local Settings\ESRI\Desktop10..

  3. If you don't see AssemblyCache, Organize > Folder and search options > View > uncheck "Hide protected operating system files (recommended)"

  4. In the directories in AssemblyCache, look for the one containing your .dll.

  5. Delete the .dll.

  6. Rebuild the project and debug. Once your add in activates you should see the cache contents get refreshed.

  7. If desired, re-hide the protected OS files.

The problem for me was that there was an old instance of my DLL in the C:\Users\\Local Settings\ESRI\DesktopX.X\AssemblyCache\ folder, and I also couldn't see \AssemblyCache because I didn't realize it was a hidden OS file. There was also a zombie instance of ArcMap running, and when I tried to delete the DLL initially it was locked. My suspicion is that what caused the problem in the first place is that I didn't quite fully shut down a debugging session of ArcMap before recompiling the code and starting another. The old DLL in the cache couldn't get overwritten because the old ArcMap instance still had it locked, and once it got out of synch with the new code the cached version no longer got updated. (I can see by file dates that the .config, .pdb, and .xml are being updated but not the .dll.)


I was dealing with the same problem, with my own add-in in totally other topic, and I inevstigated the followings:

At first, start debug and in the menu choose the following window Debug >> Windows >> Modules, where you can see what modules were loaded at the debug start up. If you can't see there the yourAddIn.dll then at least you know that it was not loaded by the studio. If you see there and you can't put the breakpoint there then the Studio loaded an old one. To check this, change the assembly's name in the project properties, rebuild the solution, start the debug and you will see the old dll loaded there. I don't know from where does the studio load this old dll.

Go to the Solution Explorer and check compare the "yourAddIn.Addin" and "yourAddIn - For Testing.AddIn" files and they may differ. The studio uses only the 2nd file in its Add-In Manager! At first change Also change the tag in it to refer to the correct dll and you may check the tag as well. For me the was set back to 0 in the "yourAddIn - For Testing.AddIn" file, so I changed it back to 1. (If you delete the bin directory of your add-in and starts the studio it will promt you and ask that would you like to remove this add-in from your add-ins list! At this point the Studio sets the LoadBehavior to 0.)

After these two change it started working again!

  • Thank you for sharing your experience and caring to provide us the details. Welcome to our community!
    – whuber
    Jan 24, 2012 at 15:25

With Visual Studio, I created a new add-in for Arcmap, and added a button and a toolbar to it. Resulting in a config file looking like this:

<ESRI.Configuration xmlns="http://schemas.esri.com/Desktop/AddIns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Description>Type in a description for this Add-in.</Description>
    <Target name="Desktop" version="10.0" />
  <AddIn language="CLR" library="ArcMapAddin4.dll" namespace="ArcMapAddin4">
        <Toolbar id="MyToolbar4" caption="MyToolbar4" showInitially="true">
            <Button refID="Microsoft_ArcMapAddin4_Button1"/>
        <Button id="Microsoft_ArcMapAddin4_Button1" class="Button1" message="Add-in command generated by Visual Studio project wizard." caption="My Button" tip="Add-in command tooltip." category="Add-In Controls" image="Images\Button1.png" />

I created some code in the constructor for the Button and put a break point in it. I started in debug mode and see that the assembly has not yet loaded:

enter image description here

I changed the button to include onDemand=false:

enter image description here

When I started arcmap again, it hit the break point. Note that if the toolbar is off at startup you would need to make it visible to cause the button constructor to be called - so in some ways it is still on demand.

  • Thanks @Kirk. Since I have restored my project from backup, it seems to work now. I usually debug a procedure that's further down the road; i.e. called from the click even of a button which was the case this time. I am pretty sure the assembly is already loaded at this point. (or should be but it's not for some reason) I will definitely try this solution the next time this happens. Aug 15, 2011 at 23:57

Had to change my addin for arcCatalog to match using framework 4 with the new 10.1 version of ArcCatalog.
Just commented out the version="v2.0.50727" and uncommented "v4.0.30319"

In C:\Program Files (x86)\ArcGIS\Desktop10.1\bin the ArcCatlog.exe xml config file

stops on break point now

Seems to be the same issue with arcmap


After I migrated an ESRI ArcGIS 10 project from one machine to the other, I encountered the error that the machine could not load the debug .pdb files for ArcMap.exe. I tried every piece of advice on this post without any luck.

Then I did the following:

I deleted the references for all Esri.* libraries in the each project that contained them, and re-added them to the project on the new machine.

This is what finally worked for me. If anyone stumbles here with this vague issue, and has tried everything else listed on this page, try this - it's quick and easy and pretty harmless. I'm not entirely sure why this had to be done, I'm guessing it has to do with looking up the libraries per machine.

This was for a project that used BaseCommands / Toolbars, and not the new Add-Ins. Using ArcGIS 10.0 and .NET 3.5 with Visual Studio 2010 on Windows 7 Pro.


For those targeting .Net 4.0 Framework, following worked for me.

  1. As per many suggestions modify ArcMap.exe.config and ArcCatalog.exe.config to target 4.0 framework
    <?xml version="1.0" encoding="utf-8" ?> <configuration> <startup> <supportedRuntime version="v4.0.30319"/> <!--supportedRuntime version="v2.0.50727"/--> </startup>
    For some reason ArcCatalog.exe.config appears locked to modify. I got around it by copying and modifying it in other directory and then replacing it.
  2. Then in the Config.esriaddinx change the Addin language to "CLR4.0"

Two possible causes come to my mind:

  1. The addin is not registered properly so the DLL does not get loaded into the ArcMap process being debugged.

  2. Your project is targeting .NET 4. Try targeting .NET 3.5 instead.

  • Targeting .Net 3.5. I just don't understand why everything would work fine and all of a sudden not. Aug 15, 2011 at 20:02

If you are coding with multiple projects in the same Visual Studio solution, you might encounter situations where Visual Studio (VS) "disables" your breakpoints and you are unable to step through your code. This happened to me recently where I couldn't step into a "dependant" DLL assembly project that was being called from my main project.

VS warnings suggested that my assembly (DLL) was out-of-date and didn't match my code exactly. There are VS options to turn off the requirement that code matches but intuitively this seemed like a bad idea and was backed-up by internet posts. I read many web sites and there are some gnarly suggestions out there.

In the end I did a search for the output DLL from my dependant machine and found several old copies in various locations on my computer (presumably from earlier experiments and project configurations). So I deleted all of them and rebuilt my solution from scratch. This fixed my problem. I guess my current project was inadvertently binding to one of the old copies somehow and not using the latest build that was being placed in my debug folder.


What worked for me was not deleting the arcmap.config.exe as described in the post by Jakub above, but setting the "supportedRuntime" tag in this file to the correct version of the Framework that you target within Visual Studio, im my case:

    <supportedRuntime version="v3.5"/>

Over a number of ArcObjects projects I compiled a list of reasons why debugging might not work for add-ins, extensions, and commands (pre-add-in). In no particular order:

  1. You are in Visual Studio's Release mode instead of Debug mode
  2. Old versions of the tool are still registered with ArcMap / ArcCatalog and these are preventing your debug version from being loaded, or other tools with the same name are registered
  3. Project / Solution needs cleaning, and if necessary go into \bin and \obj and delete any lingering files
  4. In some cases breakpoints can only be hit after the tool has been activated (on-demand)
  5. If no breakpoints are hit it's possible an exception is occurring in the constructor and the tool never runs. Check by showing all CLR exceptions in the debug menu
  6. Entries in C:\Users\<name>\Local Settings\ESRI\DesktopX.X\AssemblyCache need deleting

Many steps require ArcMap is restarted. If all else fails a machine restart is an easy fallback but I've only once had this make a difference.


What worked for me was discribed by AnthonyWJones in https://stackoverflow.com/questions/7192361/silverlight-project-wont-enter-debug-mode: "Open the properties of the associated Web Project. Select the Web Tab. Scroll to the bottom and in the "Debuggers" section make sure "Silverlight" is Checked."


I had this happen to me once or twice. If I remember correctly, I was able to get the breakpoint working when I made a minor code change, which meant that the application was rebuilt. What happens when you build or rebuild your project?

  • I tried rebuilding the project and made several changes but still the breakpoints were "dead"... Aug 15, 2011 at 23:59

I can't believe more people are not having this problem. I now run into this almost every time i am improving and debugging my add-ins.

None of the above mentioned solutions work. To fix this I need to delete the entire project and restore it from backup. This leads me to believe that something in the particular project has become corrupt since it usually start happening when ArcMap crashes during debugging.

  • Are there lingering ArcMap.exe processes? Sometimes add-ins, extensions, commands etc can hold onto a resource or cause a race condition that prevents ArcMap from exiting completely.
    – blah238
    Oct 25, 2011 at 21:16
  • No ArcMap.exe processes running. I now have a reply from ESRI staff to Try removing <supportedRuntime version="v2.0.50727"/> from arcmap.exe.config, in the bin directory. However, i am not sure where from am I removing this item and I've just restored my project from backup and it is now working. When I know more about this fix i will crash ArcMap during debugging which usually makes this happen and will give it a try. Oct 26, 2011 at 13:12

Are you creating your project using Framework 4? I had the same problem, but when I switch to Framework 3.5, it works fine.


try to clean and rebuild then run without debugging, when application runs attach it in VS


I know this might sound too obvious but I'll mention it anyway is that you need the appropriate edition of Visual Studio. For example this problem might occur with an express edition of a given year while it could work with an ultimate edition. If you're using say 2010, try switching to 2012. Then try switching from express to ultimate. I would do this if you haven't already before messing with symbol load issues. ESRI does provide information on downloading the symbols to the cache as mentioned in the link above (ArcObjects 10 .NET SDK Help ). However, this may not be necessary. Make sure you're using the appropriate .net framework also before debugging, for example .net 3.5 on the older editions. In addition ensure that in the project properties under the debug category your pointing to the path for the arcmap exe which resides in the desktop bin folder although it should be there anyway when you begin an add-in.


I had the same problem except with the ArcGIS PRO SDK (C#/.NET/Visual Studio Community 2022). I am assuming my answer is useful here and so posting it here and tagging it for instead of asking and answering myself.

When my breakpoints failed, my research on this issue (primarily on Stack Overflow) focused in on issues with missing PDB files. Indeed, reviewing Debug::Windows::Modules indicated problems with numerous PDB files.

My research included reading through most if not all related posts at SO.

I finally focused on one specific file, the PDB file for ArcGISPro.dll, and contacted Esri support about this one missing file. After digging in deeper with them, and trying many of the same proposed solutions offered both here and @ SO, the tech suggested uninstalling and re-installing Visual Studio (albeit an answer hinted at above by @jakub-sisak-geographics).

Worked like a charm and my breakpoints are working again.

I still see PDB issues listed in the Debug::Windows::Modules, but since my breakpoints are working I am, for now, ignoring the PDB issues.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.