Share via

SetFileIoOverlappedRange messages in SQL Server Errorlogs

  • Article

Hi Everyone,

I had recently to understand why a SQL Server had repeated occurences of "SetFileIoOverlappedRange failed, GetLastError is 1314" in its errorlog.

Because the web lookup of the main keyword would likely lead to https://support2.microsoft.com/kb/2679255/en-us, that (rightfully) would make the DBA worried about what could possibly be happening on the Server.

Because Os error 1314 is ERROR_PRIVILEGE_NOT_HELD, other research would also lead to double checking SeLockMemoryPrivilege  as specified in https://msdn.microsoft.com/en-us/library/windows/desktop/aa365540(v=vs.85).aspx, only to find out that the privilege is set for SQL Server Service Account (telltale item is the entry 'Using locked pages in the memory manager.' in startup section of errorlog).

Finally, testing would show that attaching a Database would generate three of those messages at every try :

2014-10-13 17:24:09.48 spid53      SetFileIoOverlappedRange failed, GetLastError is 1314
2014-10-13 17:24:09.54 spid53      Starting up database 'dummy'.
2014-10-13 17:24:09.55 spid53      SetFileIoOverlappedRange failed, GetLastError is 1314
2014-10-13 17:24:09.55 spid53      SetFileIoOverlappedRange failed, GetLastError is 1314

So what have we got here ?

Well the thing is, during the attach operations, some part of the file operations will be done under the client's security context.

But if SQL Server was started with SeLockMemoryPrivilege, then it would attempt to generate IOs that use SetFileIoOverlappedRange API, including the IOs that take place under the client's context during special 'attach' code.

If the Client's account does NOT have SeLockMemoryPrivilege enabled, then the attempt by SQL to use the API would fail and generate the messages previously described in the Errorlog.

Conversely :

  • If SQL Server account doesn't have SeLockMemoryPrivilege, then the situation is avoided.
  • If both SQL Server Account and the Client's (user) interactive account have SeLockMemoryPrivilege, then the situation is avoided too.
    • note that this would likely require to start SSMS 'as administrator'. Failing that, the message will appear
    • also note that enabling the privilege requires a log out/log in to activate.

 

So the main thing to remember is that this error message in this context (attach DB) can safely be ignored and is not related to the scribbler issues described in https://support2.microsoft.com/kb/2679255/en-us,

The only possible consequence can be a de-activation of SetFileIoOverlappedRange API for the DB until the SQL Service is restarted. This should have a very limited impact, and can be easily mitigated by restarting the DB (put it offline and online again) right after an attach.

Hope this helps removing a bit of confusion on the topic :)

 

Regards,

 

Guillaume Fourrat

Escalation Engineer

Microsoft France