Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
SOLVED

MDE ATP prevents Visual Studio 2019 16.9 from loading

Copper Contributor

I recently began the deployment of Visual Studio 2019 16.9.1 to our developers and discovered that it will not correctly load or become usable due to ATP thrashing the application as it starts.  I'm not sure what it is about 16.9 but my guess is it's loading more threads at startup than 16.8 or 16.7 did and ATP aggressively scans all of the threads as it starts.  Because of how aggressive it is the threads fail to start in a timely fashion resulting in a ton of errors in the GUI when run as a normal user or not even loading when run as admin.

 

On systems where VS 2019 16.9.1 won't load I reverted them back to the 16.7 and 16.8 branch to test and those load with ATP running.  I tested removing ATP and 16.9 works.  I also spun up a couple test VMs to verify combinations of applications and configs and in all cases ATP + 16.9 results in VS 2019 failing to load or be usable.

 

Start VS 2019 as normal user error

LeithTussing_0-1615900763989.jpeg

Start VS 2019 as admin error

LeithTussing_1-1615900782046.jpeg

 

4 Replies
We updated some test systems to Visual Studio 16.9.2 and the issue continues to happen.
Hi Leith,

1. Have you configured any ASR rule?
2. Are you able to see any alert in ATP portal?
We were just finally given access to the portal, there were no events. There are also no ASR rules configured. We do have a ticket with MS now for this.
best response confirmed by LeithTussing (Copper Contributor)
Solution
There were 2 issues going on. The recently installed MDE ATP was thrashing so MS's guidance from our case was the exclude the main VS2019 process. The other was a bug in VS2019 16.9.1 & 16.9.2 that 16.9.3 corrects causing one of the components to crash.
1 best response

Accepted Solutions
best response confirmed by LeithTussing (Copper Contributor)
Solution
There were 2 issues going on. The recently installed MDE ATP was thrashing so MS's guidance from our case was the exclude the main VS2019 process. The other was a bug in VS2019 16.9.1 & 16.9.2 that 16.9.3 corrects causing one of the components to crash.

View solution in original post