Your app has entered a break state, but there is no code to show because all threads were executing external code (typically system or framework code)

Visual Studio 2017 breaks in debug mode and displays the message:

> Your app has entered a break state, but there is no code to show > because all threads were executing external code (typically system or > framework code).

The message is in the Break Mode Window.

What to do?

Click on "Continue execution"

Then you will have the stacktrace in the output tab

1. First check all your common exception setting run time in your visual studio so that you can get the actual error.

2. During loading you application check that is their any method which is throw new NotImplementedException();

In my case i use INavigationAware which was throw new NotImplementedException(); i just remove those

3. In you all project update all from nuget.

4. Clean and rebuild you project.

In my case I just need to restore the list of exception settings to the default settings.

I got this situation when my "Platform Target" in my Project Properties was set to "Any CPU" and "Prefer 32-bit" was selected.

I switched Platform Target to "x64" since I am using 64-bit assemblies and then I could run/debug normally.

This solution is for people who get this error in WPF application. I got this error when i moved mainwindow.xaml to view folder and forgot to update in App.Xaml. after updating as StartupUri="View/MainWindow.xaml" the main window loaded without warning.

For me, I received the error when my console application was set in Release Mode. Switching to Debug mode fixed the issue.

Check for any case of circular dependency while injecting dependencies.

This type of issue please check property and Accessories. We should return correct field and check value field.

Example:

private string NameField;
public string Name
{
  get
  {
  return NameField;
  }
  set
  {
  nameField=value;
  }
}

Just had a similar issue in VS2019, I ended up needing to rebuild all in order to resolve the issue despite having manually built many times.

I hit this earlier today with a C++ console application. Disabling "just my code" and selecting the Microsoft symbol server fixed this issue.

Tools → Options → Debugging → General → Untick "Enable Just My Code"

Tools → Options → Debugging → Symbols → Tick "Microsoft Symbol Servers"

First drag the Break Mode Window to the Call Stack Window to get an overview again.

Then, check whether the Solution Explorer Window is in source mode. The 4th button from the left has a drop-down. Make sure the *.sln, i.e. classic solution mode is selected.

I didn't know this and was surprised to find that in "source mode", i.e. the other possibility, the above mentioned message is displayed.

I got this when I accidentally set the startup project to a class library instead of the end project (in this case, a WPF application).

Observed same error and resolved it by:

• Removing duplicate configs from section
• Removing extra/unused characters (by mistakenly entered)

This occurred for me when I placed the connectionStrings config item in the wrong spot in app.config.

check your Ip address (it must be the same as the listening adress if you'r not using the loopbach address)

Error: IOException Cannot locate resource

Most of the time this error occur when using visual studio form applications.

To solve this error you can go to your App.xaml file and edit SratupUri to your current xaml form name.

<Application x:Class="AppName.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             StartupUri="MainWindow.xaml">
    <Application.Resources>
    </Application.Resources>
</Application>

You can also experience this issue if you've altered the build process with something like this to remove the PDB files. Typically I recommend if you want to remove the PDB files make the configuration specific to the "Release" configuration:

<Target Name="RemoveTranslationsAfterBuild" AfterTargets="AfterBuild" Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <RemoveDir Directories="@(FluentValidationExcludedCultures->'$(OutputPath)%(Filename)')" />

    <ItemGroup>
        <PDBFilesToDelete Include="$(TargetDir)\*.pdb"/>
    </ItemGroup>
    <Delete Files="@(PDBFilesToDelete)" />
</Target>

Then Follow @Eric's recommendations when debugging run the build under the "Debug" configuration.

I got similar issue, after spending 2 days we figured out it was due to my application was terminated from out side at the same time I was debugging.

Had the same problem, this was due to having the build set to release build. Then when asked if I would like to debug, I accidentally clicked ignore always.

I changed it to debug mode in the properties settings but the error was still there.

You will also need to change this in the configuration manager from Build/configuration manager and set Configuration to Debug as well.

Same here. Reinstalling VS 2019 solved it.

Even though this is an older post, I thought the solution to my problem could help others looking for an answer to this problem.

Using the above suggestion from Led Machine - to see the stack trace, I found the following top lines.

Exception Info: System.NullReferenceException at System.Web.ThreadContext.AssociateWithCurrentThread(Boolean) at System.Web.HttpApplication.OnThreadEnterPrivate(Boolean) at System.Web.LegacyAspNetSynchronizationContext.CallCallbackPossiblyUnderLock(System.Threading.SendOrPostCallback, System.Object)

Googling this stack trace, sent me to this page: https://techcommunity.microsoft.com/t5/iis-support-blog/crash-at-system-web-legacyaspnetsynchronizationcontext/ba-p/1536553

Apparently, the problem was related to my application being configured to use Legacy ASP.NET Synchronization Context, and in certain parts of the code, I was using some new features, such as Tasks. The old (Legacy) context cannot handle some asynchronous calls properly and this leads to the crash as observed in the above.

The fix is to insert the following line in your web.config:

<appSettings>
<add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />
</appSettings>

I had a similar issue when debugging a VSTO Excel add-in. After trying everything, I resolved the issue by disabling a realtime protection module on my antivirus software.