Memory mapped file may cause "0xC0000006: In page error" after invoking LockFile() concurrently - by Lasse Reinhold

Status : 


Sign in
to vote
ID 788390 Comments
Status Active Workarounds
Type Bug Repros 0
Opened 5/22/2013 7:20:33 AM
Access Restriction Public


UPDATE 23-May-2013: Please use! I accidently used LockFile instead of LockFileEx, but the problem persists.

I have attached a detailed test program that triggers a page fault

It invokes LockFile(LOCKFILE_EXCLUSIVE_LOCK) from two different threads at exactly the same time (this seems crucial) on a file located on a network drive (works fine on non-network drives). The succeeding thread may then page fault when accessing it through memory mapping.

Page fault occurs in around 1 out of 10 runs on Windows 8 + Visual Studio 2012, both in debug and release mode.
Sign in to post a comment.
Posted by Microsoft on 8/7/2013 at 4:48 PM
Thank you for submitting this bug. This site is focused on accepting bugs for Visual Studio and .NET Framework, however, this issue appears to be related to the Windows operating system so we have transferred it over to the Windows team for review. further support. Should more information be needed, someone from the Windows team will follow up with you. We’ve created some online forums where you can ask questions, post issues and get answers from other preview testers and Microsoft support professionals. We encourage active participation in these forums as the best way to provide feedback to Microsoft.

•Visit the Windows 8.1 Preview forum (
•Visit the Internet Explorer 11 Preview forum (
•Visit the developer forums for building apps (
•Visit the IT pro forums for Windows 8.1 business features (
Posted by Stephan [MSFT] on 7/16/2013 at 10:28 AM
Thanks! I've reactivated this bug and sent it to our Windows SDK contact.

Posted by Lasse Reinhold on 7/16/2013 at 6:05 AM
Hi, sorry, I missed the e-mail that said that there was a reply!

I've uploaded with all the corrections you mentioned (no STL).

We found out that a few other operating systems and files have low coherence for files that are memory mapped and reside on network drives.

But even if it's due to specifications, it's still a problem that all Windows API functions return success.
Posted by Stephan [MSFT] on 7/15/2013 at 5:30 PM
Hi again,

It's been over a month, so I'm resolving this bug as Not Reproducible.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
Posted by Stephan [MSFT] on 6/5/2013 at 2:29 PM

Thanks for reporting this issue. I'm Microsoft's maintainer of the STL, and this is currently assigned to me because you used <thread> and <atomic> for synchronization. However, this issue doesn't appear to have anything to do with the STL itself (instead it's with the Windows API). I tried to reproduce this in a Win8 VM, but it didn't crash for me. Since you can reproduce this at will, can you rewrite your test case to use the CRT's _beginthreadex() and intrin.h's _Interlocked functions for synchronization? (Using stdio.h for printing would also be great.) That'll rule out STL involvement and get us closer to the ultimate problem.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
Posted by Microsoft on 5/22/2013 at 7:55 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 5/22/2013 at 12:54 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(