Author Topic: [Bug] Windows Search service and naughty oplock  (Read 1348 times)


  • Administrator
  • Hero Member
  • *****
  • Posts: 1581
[Bug] Windows Search service and naughty oplock
« on: May 28, 2017, 01:17:09 pm »
There were several reports that RulesPack could randomly hang once or several times for ~90 seconds each while installing rules. It was a real pain to reproduce, let alone to debug. So it can be useful for people who encounter strange hangs while calling LoadUserProfile API.

The problem here starts from calling LoadUserProfile API. This call goes to svchost.exe process who copies several folders from Users\Default to a newly created user (here I assume that's the first LoadUserProfile call after new user creation). Meanwhile Windows Search as SearchProtocolHost.exe process may open files and folders for indexing, set an oplock (opportunistic lock), do his thing, including reopen, and eventually close them. When oplock is broken (Breaking an opportunistic lock is the process of degrading the lock that one client has on a file so that another client can open the file, with or without an opportunistic lock. When the other client requests the open operation, the server delays the open operation and notifies the client holding the opportunistic lock. - from MSDN), separate second thread waits for the processing to complete (signal from the first thread) or for the timeout of 90 seconds to expire and then allows to break oplock. While oplock isn't broken, file open operation is pending. So in normal functioning the first thread quickly finishes what it was doing and signals the seconds thread, oplock is successfully broken, noone hangs. But if in the moment after the oplock was set but before the file was opened someone tries to open the file thus commencing oplock breakage (breaking?), then the first thread will also hang on the same oplock trying to reopen the file. So we have situation: some unlucky thread (in my case it was RulesPack) is hanging waiting for the oplock, the first thread is hanging waiting for the same oplock, the second thread is hanging waiting for the first thread. This deadlock will last for 90 seconds until second thread timeout expires.

Possible solution is to disable Windows Search service. Or update Windows, fortunately it was fixed somewhere around Windows 10 1607.
« Last Edit: June 19, 2017, 12:04:34 pm by fixer »