We have a similar problem on some of our Win 11 developer machines. The scale of the impact varies between the affected systems. However on all affected systems I was able to verify the problem by the following scenario while all unaffected systems do not trigger this behavior:
- starting powershell.exe right after startup seems to come up as fast as excepted
- starting visual studio (or some other programs like inventor) seems to trigger the problem: after visual studio is started a newly started powershell (and all subsequently entered commands) takes at least a few seconds to show up
- note: when leaving the started visual studio untouched in the background for at least 10 to 20 minutes seems to mediate the delayed powershell execution
This issue seems to be introduced by the April (Update KB5036893 (win11) + KB5036620 (.net)). If these updates were uninstalled for testing the issue dissapears. After reinstalling these updates the issue shows up again.
I've done some porfiling with procmon.exe. I've filtered the output by only showing operations that took at least 3 ms to execute. If the problem is not triggered the list remains empty. If the problem was triggered (by starting VS e. g.) there is a list with a bunch of entries for file operations triggered by MsMpEng.exe reading ni.dll files within C:\Windows\assembly\NativeImages... . The most of these entries took around 8 secounds to executed and have a OPLOCK HANDLE returncode as you can see in the following screenshot:
Only if the Issue is triggered there are also a lot of "Internal signature match:subtype=Lowfi" in the MPLog-file of the Defender.
...
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x8bf5ff3a
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x8bf5ff3a
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x6cbc5099
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x8bf5ff3a
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x6cbc5099
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x6cbc5099
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x8bf5ff3a
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x8bf5ff3a
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x8bf5ff3a
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x8bf5ff3a
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x8bf5ff3a
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x6cbc5099
Internal signature match:subtype=Lowfi, sigseq=0x0001AABD2A1C008D, sigsha=241f62fb3e4bd53504b45d010de7891beded94da, cached=true, source=16, resourceid=0x8bf5ff3a
...
When excluding the C:\Windows\assembly\NativeImages... directory in defender settings the issue disappears immediately. While this is helpful for testing excluding this directory from defender is a bad idea for production use.
Since we use a lot of ASR rules I've tested if one of these rules may cause the performance issue. At least on our systems the "EnableControlledFolderAccess" rule seems to be the "root" cause of the issue. If I disable this rule the issue disappears as well.
At this points my investigations aren't finished yet. But probably my previous findings are helpful for others facing the same problems or someone has an idea for further investigations.
Greetings
Simon