Case of System Becoming Unusably Slow when Visual Studio Hit A Breakpoint

Had an application being debugged with Visual Studio 2019 on Windows 10 21H1. The application itself was consuming nearly no system resources at all, machine was running nice and quick. Fast SSD, more than 16 GB free ram, CPU not close to being maxed out, etc.

However as soon as a breakpoint was hit in this application, the entire system became extremely slow to the point of being unusable. The only way to resolve the freeze was to hit “F5” and continue, and even that key press could take a minute to process before Visual Studio actually continued.

To start took a trace using in-built Windows performance recorder, while reproducing issue:

wpr -start GeneralProfile -start CPU -start DiskIO -start FileIO

Once issue was reproduced, I let system stay in a unusable state for about 30 seconds before trying to continue application. Once application had continued to debug I was able to stop Windows performance recorder

wpr -stop slow_debug.etl "System Slow on Breakpoint"

When the breakpoint was hit CPU usage went up to 100% and CPU usage went back to normal on resumption. You would think at a breakpoint the CPU should be doing less…

Zooming into high CPU section and selecting Flame by Process, Stack several potential culprits are specified, all belonging to Visual Studio

  • ServiceHub.DataWarehouseHost.exe
  • ScriptedSandbox64.exe
  • DevEnv.exe

Viewing the stacks of these didn’t help me come to any further conclusions. I decided to add the “Priority” column, and noticed the EXE being debugged “TestApp.exe” was constantly changing priority level

Each process in Windows belongs to one of the following priority classes:

  • IDLE_PRIORITY_CLASS
  • BELOW_NORMAL_PRIORITY_CLASS
  • NORMAL_PRIORITY_CLASS
  • ABOVE_NORMAL_PRIORITY_CLASS
  • HIGH_PRIORITY_CLASS
  • REALTIME_PRIORITY_CLASS

Checking the application being debugged found it was calling SetPriorityClass with ABOVE_NORMAL_PRIORITY_CLASS and HIGH_PRIORITY_CLASS prior to breakpoint being hit.

Commenting out this priority change allowed breakpoint to hit without making the system unusuable.

Microsoft’s documentation comes with the warning when using HIGH PRIORITY CLASS:

HIGH_PRIORITY_CLASS. Process that performs time-critical tasks that must be executed immediately. The threads of the process preempt the threads of normal or idle priority class processes. An example is the Task List, which must respond quickly when called by the user, regardless of the load on the operating system. Use extreme care when using the high-priority class, because a high-priority class application can use nearly all available CPU time.

About chentiangemalc

specializes in end-user computing technologies. disclaimer 1) use at your own risk. test any solution in your environment. if you do not understand the impact/consequences of what you're doing please stop, and ask advice from somebody who does. 2) views are my own at the time of posting and do not necessarily represent my current view or the view of my employer and family members/relatives. 3) over the years Microsoft/Citrix/VMWare have given me a few free shirts, pens, paper notebooks/etc. despite these gifts i will try to remain unbiased.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a comment