Today I was called in to take a look at a weird excel addin error. Suddenly on all Windows 2016 terminal servers from a specific customer, they got the following error when opening excel:
The first thing that will come to mind, is looking at the latest Windows and office patches that have been installed. And so I did, after removing all the latest patches within a test environment the problem remains. So, I excluded patching problems.
What’s next? AppLocker logs also didn’t show any blockades, so my second thought was the antivirus. I opened the Windows defender / operational log but didn’t encounter anything that pointed me in the right direction.
But I was pretty sure Defender was blocking these actions, why you think? Because when you don’t know exactly what is happening with a process, you need to run Procmon, so I did. Running Procmon showed me the Defender MsMpEng.exe process each time when turning on this addon.
It’s a good thing Microsoft defender also logs his actions somewhere else, it also uses a plain text file which you can find in the C:\ProgramData\Microsoft\Windows Defender\Support folder.
Opening this text file showed me some more information.
Block on rule 0x3b576869-…, State=1, Inheritance=0x0, Parent=”C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE”, ParentCmdline=””, Target=”C:\Users\superuser\AppData\Local\Temp\34\Deployment\VH0GGBT9.QR1\EE2X5TET.NY5.application”, TargetCmdline=””, InvolvedFile=””
So, a “rule” is blocking this process suddenly? Without proper event logs? Searching for 0x3b576869 resulted in zero results but searching for 3b576869, showed me some more results.
Add-MpPreference –AttackSurfaceReductionOnlyExclusions “C:\Program Files (x86)\Microsoft Office\Office16\excel.exe”
After adding this exclusion, the AFAS excel plugin was working again. That’s the first and most important result but… I really wanted to know why there weren’t any logs in the Defender operational log.
The first place to look when you suspect defender is not logging anymore would be:
Start has to be configured to: 1.
As shown above start has the correct value so what else is happening? But then I realized something…
So, you will need at least Windows server 1803. But our servers were the 1607 version.
After some digging, I found out the ASR rules were automatically configured when the server was deployed even when ASR should not be available in this Windows version. To be 100% sure I installed the same software on a 2019 terminal server. Take a look at the Defender operational log below! Just as you expected, a nice warning.
But why out of the blue was it blocking this software with ASR? I still don’t know, the only thing I can guess is it looks like a combination of things.
The first one will be the antivirus engine upgrade some weeks ago in combination with the 2020-10 KB4580346 update last weekend.
Only using the Windows event log for troubleshooting is not enough, use Procmon and look for other log files. It’s good to know Windows defender also has a nice plain text file to search in. Last but not least, it’s very nice to see ASR rules are working on Windows 2016 version 1607 even when event logging is not working as you’d expect.