The Symptom

Users were experiencing a 5-15 second delay when saving a document to OneDrive or SharePoint, during which Word would show as “not responding”.

All machines in question use App Control for Business (WDAC).

The Cause

During the “not responding” period, Word is attempting to start the Web Client service, which is set to Manual.

svchost.exe launches, tries to load the WebClnt.dll library, but this is blocked by App Control for Business.

Word has to wait for this attempt to time out, before then giving up and saving anyway.

The Fix

Setting the Web Client service start type to Disabled prevents Word from attempting to start the service, fixing the delay.

The Diagnosis Process

Event Tracing for Windows and UIforETW strike again, along with the incredible utility of the public symbols for Office.

The process was similar to that which I documented here, where the process of saving comments in Word caused a hang. The key is to click Trace > Load Symbols to ensure we have function names in the trace.

Drilling down to the problem time area and then digging into the amount of time we spend in each function revealed that the time was being spent in davhlpr.dll!TriggerStartWebclientServiceIfNotRunning.

Well this does indeed sound like something to do with the Web Client service!

I’d also separately noticed frequent events in the CodeIntegrity Windows Event Log relating to WebClnt.dll. This library is blocked by the default rule set for App Control for Business, as apparently it can be used as a bypass for the feature.

Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. An attacker can use these applications or files to circumvent application allow policies, including WDAC:

…

• webclnt.dll/davsvc.dll

Code Integrity determined that a process \Device\HarddiskVolume4\Windows\System32\svchost.exe) attempted to load \Device\HarddiskVolume4\Windows\System32\WebClnt.dll that did not meet the Enterprise signing level requirements.

The error message is misleading — the DLL is signed (although I believe via a .cat file buried somewhere, as it’s part of the operating system). It’s actually this default rule set that explicitly blocks it, despite it being part of the OS!

Fair enough, I suppose. The difficulty here is that the process of Word trying to start the service, spawning a svchost.exe, only for it to be unable to to load webclnt.dll is taking seconds and seconds, while the user is unable to do any work. This adds up if it happens on every save of a document.

I had the idea perhaps to enable this DLL via an App Control rule, but this didn’t go anywhere, despite a test to attempt to exclude webclnt.dll from the ruleset.

Instead, I set the service to Disabled and tried to reproduce the issue.

Suddenly, instant save!

The service being disabled doesn’t seem to have any negative impact on Office applications — and indeed I can be quite confident this won’t break any other functionality our users rely on, since the Web Client DLL has been consistently blocked in all other contexts too!

It’s another W for Event Tracing for Windows, and the publication of the symbols for Microsoft Office. Thank you, Microsoft!