Hogging CPU - MSVCR120? SetUnobservedExce

Saw a strange failure this afternoon. I could feel my Surface Book was getting hot, and saw something hogging 10 to 30% of my CPU. Resource Monitor pointed to GWCtlSrv, and Process Explorer showed this:

It kept creating more and more of the “MSVCR120? SetUnobservedExce…” threads. I couldn’t find any other clues there. Closing the GlassWire app did not stop this, it seemed to make it worse. Stopping the service did stop the CPU hogging, and restarting the service did not bring it back.

I thought the problem was handled, but then the whole computer locked up solid - no response to any controls, clock and status indicators not updating, Ctrl+Alt+Del ignored. Had to kill power to recover. No idea if that was related to GlassWire - the only thing in the logs at that point is Windows Defender deleting history and changing status. I was obviously using Process Explorer and Snipping Tool, but I do that a lot with no problem. It seemed the crash was a continuation of the GlassWire problem.

I doubt it will happen again, but wanted to report it in case it might connect with other reports. BTW, this is 1.2.88.



MSVCR120 appears to be a Microsoft runtime library and I don’t think it’s related to GlassWire. I searched around Google and couldn’t find any about this file doing this so I’m not sure what to suggest.

Could you try disabling network auto-scanning and switch to our manual scan and see if it helps with your resource usage?

To disable Network auto-scanning completely create a text file called glasswire.conf and place it in the c:\programdata\glasswire\service folder. Add this string to the text file: enable_network_scan = false then restart the GlassWire service. We plan to add a setting for this in the future.

@Ken_GlassWire, this looks like it does relate to GlassWire. And it does look like it is using a lot of CPU: 3.48 is more than I’ve seen for one thread in GlassWire.

MSVCR120.dll is the Microsoft Visual Studio 2013 C Runtime. It is a DLL used by GWCtlSrv.exe as confirmed by running SysInternal ListDLLs. It is not a DLL included with Windows by default so it has to be installed. Do you use Microsoft Visual Studio for software development?

My understanding is that SetUnobservedException is to trap (or observe) an unobserved exception error that would otherwise crash the application. I wasn’t able to confirm the same behaviour on my install because I haven’t yet installed the Windows Debugging support used to display the thread information correctly. This code is likely to be standard for all of us but is it possible that this is from one of your special debug versions of GlassWire?

Listdlls v3.2 - Listdlls
Copyright © 1997-2016 Mark Russinovich

GWCtlSrv.exe pid: 2760
Command line: “C:\Program Files (x86)\GlassWire\GWCtlSrv.exe”

Base Size Path
0x0000000000cb0000 0xf10000 C:\Program Files (x86)\GlassWire\GWCtlSrv.exe
0x000000002fd60000 0x1d1000 C:\Windows\SYSTEM32\ntdll.dll
0x0000000077ac0000 0x52000 C:\Windows\System32\wow64.dll
0x0000000077a30000 0x77000 C:\Windows\System32\wow64win.dll
0x0000000077ab0000 0xa000 C:\Windows\System32\wow64cpu.dll
0x0000000000cb0000 0xf14000 C:\Program Files (x86)\GlassWire\GWCtlSrv.exe
0x00000000771b0000 0x183000 C:\Windows\SysWOW64\ntdll.dll
0x0000000075d00000 0xe0000 C:\Windows\SysWOW64\KERNEL32.DLL
0x00000000745e0000 0x1a1000 C:\Windows\SysWOW64\KERNELBASE.dll
0x0000000073bc0000 0x94000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.14393.447_none_5507ded2cb4f7f4c\comctl32.dll
0x0000000076240000 0x77000 C:\Windows\SysWOW64\ADVAPI32.dll
0x0000000074050000 0xbe000 C:\Windows\SysWOW64\msvcrt.dll
0x00000000761f0000 0x41000 C:\Windows\SysWOW64\sechost.dll
0x0000000073f20000 0xc1000 C:\Windows\SysWOW64\RPCRT4.dll
0x0000000073c70000 0x1e000 C:\Windows\SysWOW64\SspiCli.dll
0x0000000073c60000 0xa000 C:\Windows\SysWOW64\CRYPTBASE.dll
0x0000000076560000 0x5a000 C:\Windows\SysWOW64\bcryptPrimitives.dll
0x0000000075e70000 0x2b000 C:\Windows\SysWOW64\GDI32.dll
0x0000000077050000 0x15b000 C:\Windows\SysWOW64\gdi32full.dll
0x0000000073dc0000 0x15f000 C:\Windows\SysWOW64\USER32.dll
0x0000000076540000 0x15000 C:\Windows\SysWOW64\win32u.dll
0x00000000715a0000 0x24000 C:\Windows\SysWOW64\winmm.dll
0x0000000071570000 0x23000 C:\Windows\SysWOW64\WINMMBASE.dll
0x0000000073c90000 0x36000 C:\Windows\SysWOW64\cfgmgr32.dll
0x0000000076450000 0xea000 C:\Windows\SysWOW64\ole32.dll
0x0000000076c00000 0x211000 C:\Windows\SysWOW64\combase.dll
0x0000000075b70000 0xe0000 C:\Windows\SysWOW64\ucrtbase.dll
0x0000000074130000 0x94000 C:\Windows\SysWOW64\OLEAUT32.dll
0x0000000075ef0000 0x7b000 C:\Windows\SysWOW64\msvcp_win.dll
0x0000000071430000 0x71000 C:\Program Files (x86)\GlassWire\MSVCP120.dll
0x0000000071340000 0xee000 C:\Program Files (x86)\GlassWire\MSVCR120.dll
0x00000000765c0000 0x63000 C:\Windows\SysWOW64\WS2_32.dll
0x00000000712f0000 0x49000 C:\Windows\SysWOW64\fwpuclnt.dll
0x00000000714c0000 0x1b000 C:\Windows\SysWOW64\bcrypt.dll
0x0000000076020000 0x46000 C:\Windows\SysWOW64\SHLWAPI.dll
0x00000000712d0000 0x1a000 C:\Windows\SysWOW64\USERENV.dll
0x0000000076010000 0xf000 C:\Windows\SysWOW64\profapi.dll
0x00000000714b0000 0xf000 C:\Windows\SysWOW64\WTSAPI32.dll
0x00000000741d0000 0x40b000 C:\Windows\SysWOW64\SETUPAPI.dll
0x00000000712a0000 0x2f000 C:\Windows\SysWOW64\IPHLPAPI.DLL
0x0000000073ad0000 0x8000 C:\Windows\SysWOW64\VERSION.dll
0x0000000075ea0000 0x44000 C:\Windows\SysWOW64\WINTRUST.dll
0x0000000075c50000 0xe000 C:\Windows\SysWOW64\MSASN1.dll
0x00000000762c0000 0x17d000 C:\Windows\SysWOW64\CRYPT32.dll
0x0000000071200000 0xa0000 C:\Windows\SysWOW64\WINHTTP.dll
0x00000000711b0000 0x4b000 C:\Windows\SysWOW64\wevtapi.dll
0x0000000076f60000 0x51000 C:\Windows\SysWOW64\WLDAP32.dll
0x0000000074790000 0x13d9000 C:\Windows\SysWOW64\SHELL32.dll
0x0000000076630000 0x56e000 C:\Windows\SysWOW64\windows.storage.dll
0x0000000076ba0000 0x45000 C:\Windows\SysWOW64\powrprof.dll
0x0000000076bf0000 0xd000 C:\Windows\SysWOW64\kernel.appcore.dll
0x0000000075de0000 0x88000 C:\Windows\SysWOW64\shcore.dll
0x0000000071160000 0x4e000 C:\Windows\SysWOW64\MSWSOCK.dll
0x000000006f2f0000 0x28000 C:\Windows\SysWOW64\ntmarta.dll
0x0000000076fc0000 0x84000 C:\Windows\SysWOW64\clbcatq.dll
0x000000006f230000 0x5e000 C:\Windows\SysWOW64\FirewallAPI.dll
0x000000006f200000 0x24000 C:\Windows\SysWOW64\fwbase.dll
0x0000000071510000 0x13000 C:\Windows\SysWOW64\CRYPTSP.dll
0x000000006f180000 0x7c000 C:\Windows\SysWOW64\DNSAPI.dll
0x00000000761e0000 0x7000 C:\Windows\SysWOW64\NSI.dll
0x00000000714e0000 0x2f000 C:\Windows\SysWOW64\rsaenh.dll
0x000000006f2e0000 0x8000 C:\Windows\SysWOW64\rasadhlp.dll
0x000000006f2b0000 0x2e000 C:\Windows\SysWOW64\FWPolicyIOMgr.dll
0x0000000070270000 0x43000 C:\Windows\SysWOW64\WINSTA.dll
0x000000006f290000 0x13000 C:\Windows\SysWOW64\dhcpcsvc6.DLL
0x000000006f160000 0x14000 C:\Windows\SysWOW64\dhcpcsvc.DLL
0x00000000702c0000 0x1f000 C:\Windows\SysWOW64\gpapi.dll
0x000000006f130000 0x2c000 C:\Windows\SysWOW64\netprofm.dll
0x000000006f120000 0x9000 C:\Windows\SysWOW64\npmproxy.dll
0x0000000074110000 0x19000 C:\Windows\SysWOW64\imagehlp.dll
0x000000006f100000 0x12000 C:\Windows\SysWOW64\napinsp.dll
0x000000006f0e0000 0x16000 C:\Windows\SysWOW64\pnrpnsp.dll
0x000000006f0c0000 0x14000 C:\Windows\SysWOW64\NLAapi.dll
0x000000006f0b0000 0xc000 C:\Windows\SysWOW64\winrnr.dll
0x000000006f090000 0x11000 C:\Windows\SysWOW64\wshbth.dll
0x0000000071040000 0x22000 C:\Windows\SysWOW64\DEVOBJ.dll

You’re showing Threads in Process Explorer so the dbghelp.dll has been updated by downloading the Microsoft Debugging tools.


Are you using a special version of GlassWire we sent you from the helpdesk, or a public version as normal?

Mine is just the normal download version. I do have Visual Studio installed, but the DLL apparently was installed with GlassWire:

I just peeked at Process Explorer while there was no obvious cpu hogging:

BTW - Is there some trick to dragging images in here without deleting all the text?

When the Thread view first opened, it was all “GWCtlSrv.exe”. There was a lot of flashing and then all the MSVCR lines appeared. They stay on the same thread numbers, rack up cycles, then let them go. Some of them are from this morning’s wake from hibernation, others from yesterday’s reboot. Both are occasionally active. Rarely some other single thread appears and closes. These all stay in the list.

The scary part is that when I first opened Process Explorer, it was showing less than 1% CPU. Over about an hour it has crept up to about 8% CPU. Usually three or four of the MSVCR threads at around 2% - but different ones every few seconds.

I just saw the post about Network auto-scanning - will go try that next.


Restarted the service. CPU usage dropped from >9 to <3, with the four or five currently active threads using under 1% each. But still 62 threads, lots of MSVCR threads in the same activity pattern.

In the app, I only have the free version. The Network tab has a “Scan” button, and clicking it immediately killed about a dozen of the MSVCR threads - but opened a lot more. There are now 386 threads there! But the worst one is only using 0.1% CPU, and the total usage dropped to about 0.3%. Process Explorer uses about 20% CPU to show that Thread dialog - close it and usage drops under 1%!

The Scan button in the app is still pulsing the three dots… Oh - it just stopped, reported 5 devices, went back to Scan. Threads went back to 72, usage is already up to 8% again. Definitely a connection…


One some networks we open up multiple threads to make the scanning happen much faster, so perhaps this is using your resources. In this case changing the “scan” to manual only should solve the problem.

Meanwhile we’re working on an update that improves this plus we’re making it easy to make the scan optional in settings.

Ken, I did create the manual scan file before that last restart and scan button test. CPU usage was low while it was scanning, despite the 386 threads. But when the scan finished, it began creeping up again. Is there some way to check whether the file was effective?

I can’t imagine what changed to make this begin happening - last Windows update session was the 19th, GW 1.2.88 installed on the 20th, but my machine only started getting hot yesterday/30th. Maybe some covert Microsoft update, I see lots of things sneaking in despite the WU service being disabled.


If GlassWire is not scanning then it should not be related to any CPU usage problems. Let me discuss with our team to confirm though.


Our team recommended to move the GlassWire database and restart the service:

The files that should be moved: C:\ProgramData\GlassWire\service\glasswire.db (-shm, -wal) and C:\ProgramData\GlassWire\service\stats folder completely. The service should be stopped before moving. We’ll keep on monitoring this issue and try to fix if we’ll find something.

Or, you could do a clean install of GlassWire with the “clean” install option instead. Please let us know if this solves your problem.

I hid the db files and re-enabled the service. It has replaced the files, but it is still showing the same threads in Process Explorer. And CPU usage is already creeping up - within half an hour PE says it is using 3% CPU. My Performance Monitor tray icons show at least that much usage, but strangely Microsoft’s Resource Monitor never shows more than 1%. Somehow it often ignores CPU hogs…

I checked the stack for one of the persistently active threads (they rack up lots of cycles, then drop back down the list while others hit the top, but the same thread numbers persist for minutes at a time, and will be back on top soon):

All of the stacks for those MSVCR threads look the same, but sometimes you catch one only partly loaded.

I captured the disk writes for GlassWire (8496) and noticed System (4) is also writing to the same GlassWire files - is that proper?

Too early to say if GW will progress to so much CPU hogging my screen gets hot, but it does seem to be creeping up. Will watch and report.

1 Like


Is your webcam/mic usage detection on? If so please switch it off and see if it helps.

We bought a Surface to test with since we have many Surface customers and GlassWire is working well for us.

Ken, I only have the free version. I assume that means the webcam/mic is totally off. I certainly can’t set it one way or the other. But I just noticed another possible clue…

I was watching Process Explorer and Resource Monitor while I opened the GlassWire app to check that setting. When the app opens, the GWCtlSrv usage drops from about 3% CPU to 1% in Process Explorer, and it drops to zero in Resource Monitor! Each of the service threads drops from peaking at 0.5 to 1% to staying under 0.1% all the time. Close the app and they all jump back up…

At least they are staying under 1% each today. In that first screenshot during the hot screen problem, individual threads were using over 3%, and racking up 10X the number of cycles they are showing today.

What could having the app open change about the load on the service?


Having the app open should increase the CPU, not decrease it. Thanks for including the info about the webcam/mic alert being turned off. I’ll ask our team and see if they have some other ideas.

Just noticed my screen warm again. Not as bad as the first time, but way more than normal. Usually the usage by GWIdlMon is much lower than GWCtlSrv, but today it is higher than before. It calls the same MSVCR routine in a similar pattern:

2216 MSVCR120.dll!?_SetUnobservedExceptionHandler@details@Concurrency@@YAXP6AXXZ@Z+0x4aa

Any progress figuring this out?



We have similar hardware and we haven’t been able to reproduce the problem yet. I apologize for not following up sooner. There is a GlassWire update that was released this morning. Please try it and let me know your results.

Just tried the update. No change. With the app open on the screen, GlassWire uses about 2% CPU. With the app closed to the system tray, nearly 3X that. Quit the app completely, and it drops to maybe 2X, but obviously more than with the app open. Seems very strange.

I will update the team. Thank you for the detailed report. I have never heard of the GlassWire CPU usage going up when our user interface is closed, it’s so strange.

We have spent a lot of time testing this.

Our Surface uses maybe 1-2% CPU maximum every time and we can’t make our Surface have this problem. Can you scan your Surface for viruses with Windows Defender or a third party antivirus after that antivirus is up to date?

Sorry for the problem.


Installed the latest Defender and other updates yesterday, scan found no problems.

Just tried GlassWire all fresh - went immediately to ~3% of my i7 Surface Book for the GWCtlSrv process, with usually three MSVCR threads using 0.4% to over 1% each, and maybe twenty more using less. Open the GlassWire app and total drops near 1%, with four MSVCR threads between 0.1% and 0.3% and the rest <0.01%.

1 Like