UnauthorizedAccessException when accessing same memory mapped file from separate IIS AppPools

[Kevin Lewis]

Here is the exception:

[UnauthorizedAccessException: Access to the path is denied.]
System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) +634
System.IO.MemoryMappedFiles.MemoryMappedFile.OpenCore(String mapName, HandleInheritability inheritability, Int32 desiredAccessRights, Boolean createOrOpen) +102
System.IO.MemoryMappedFiles.MemoryMappedFile.OpenExisting(String mapName, MemoryMappedFileRights desiredAccessRights, HandleInheritability inheritability) +119
MaxMind.Db.MemoryMapBuffer..ctor(String file, FileInfo fileInfo) +344
MaxMind.Db.Reader.BufferForMode(String file, FileAccessMode mode) +144
MaxMind.GeoIP2.DatabaseReader..ctor(String file, IEnumerable`1 locales, FileAccessMode mode) +91

I have confirmed it is not a permissions issue, and it works fine when using FileAccessMode.Memory.

The problem only occurs when the second app pool (running under a different identity) tries to open the memory mapped file.

[Gregory Oschwald]

Re-opening this as the fix was reverted. We might have to make it optional or explore other fixes. I wonder if loading it explicitly in the Local\ namespace would avoid the collision that appears to happen.

[David Warner]

I'm very interested in seeing this issue fixed - we're currently forced to load the database into memory to work around it in our websites.

I can confirm that @coolkev's patch works just as well when Global\ is changed to Local\. Presumably there's some benefit to having it in the global namespace, however, so is it worth adding a new member to the FileAccessMode enum (perhaps MemoryMappedGlobal) to enable this functionality?

For what it's worth, the IIS app pool user appears to have the permissions to create global objects.