Creating shared memory on Windows always fails

Hello, I’m trying to create a shared memory object using the Unreal C++ API. I am on Windows 8.1 x64. Here is my trouble code:

FPlatformMemory::SharedMemoryRegion* SharedMemoryRegion =
             FPlatformMemory::MapNamedSharedMemoryRegion(
             TEXT("MySharedMemory"),
             true,
             FPlatformMemory::ESharedMemoryAccess::Write 
                 | FPlatformMemory::ESharedMemoryAccess::Read,
             1000);

The FPlatformMemory::MapNamedSharedMemoryRegion always fails and in my logs I receive this message:

LogHAL:Warning: CreateFileMapping(file=INVALID_HANDLE_VALUE, security=NULL, protect=0x4, MaxSizeHigh=0, MaxSizeLow=262168, name='Global\MySharedMemory') failed with GetLastError() = 5

The GetLastError() function return value corresponds to this Windows System error code:

ERROR_ACCESS_DENIED
5 (0x5)
Access is denied.

I don’t think it’s a privilege issue on my part. I am in an administrator account.

When I try to step through the MapnamedSharedMemoryRegion() function, the visual studio debugger steps through all if statements as if they don’t exist.

This issue has plagued me since Unreal 4.7.

Thanks

Having the same issue.

The funny thing is that if I implement shared memory in my game using the Windows API everything works fine. Something tricky is happening with the Unreal Engine code.

Finally… a breakthrough of sorts! Here is what I did…
I changed from the default 64 bit debug game build to a 32 bit windows build. This then exposed the normal project properties I was used to seeing, rather that the very abbreviated version. I turned off all optiizations with /Od. It seems that once you have altered the default settings of project settings, you can go back to a 64 bit build, and you still can see all options.

Then I added the following includes:

#include
#include
#include
#include

to the beginning of my “myprojectPawn.cpp” c++ file

then in the initialization code for myprojectPawn object, I added:

#define BUF_SIZE 256
//TCHAR szName[] = TEXT(“Global\MyFileMappingObject”);
TCHAR szMsg[] = TEXT(“Message from first process.”);
HANDLE hMapFile;
LPCTSTR pBuf;

hMapFile = CreateFileMapping(
	INVALID_HANDLE_VALUE,    // use paging file
	NULL,                    // default security
	PAGE_READWRITE,          // read/write access
	0,                       // maximum object size (high-order DWORD)
	BUF_SIZE,                // maximum object size (low-order DWORD)
	L"mappedfilename");                 // name of mapping object

if (hMapFile == NULL)
{
	_tprintf(TEXT("Could not create file mapping object (%d).\n"),
		GetLastError());
	return;
}
pBuf = (LPTSTR)MapViewOfFile(hMapFile,   // handle to map object
	FILE_MAP_ALL_ACCESS, // read/write permission
	0,
	0,
	BUF_SIZE);

if (pBuf == NULL)
{
	_tprintf(TEXT("Could not map view of file (%d).\n"),
		GetLastError());

	CloseHandle(hMapFile);

	return;
}


CopyMemory((PVOID)pBuf, szMsg, (_tcslen(szMsg) * sizeof(TCHAR)));
_getch();

For the first time I’m now getting a valid pointer to the hMapFile.

I can’s say that shared memory is working yet, as I need to keep working, but finally getting a valid pointer back is a big step forward.

Hope this helps…

Now confirmed… it is actually working… Controlling the attitude of my ownship in unreal from an external console application.

Are you using the Unreal Engine API or are you directly going through Windows API for shared memory? I’ve implemented a shared memory class that will take care of using Windows Shared memory for you, mind you that this class only works on Windows, so you’d have to implement your own stuff for Linux:

Windows Shared Memory source code

Hi jgcoded, from the nature of this latest comment it seems that you were able to solve your issue. Is this the case? If I am mistaken please let me know and I’ll try to assist you with this problem.

Hi , unfortunately I only found a work-around to my problem, and not a solution. My work-around was to not use the Unreal Engine C++ API for shared memory. Instead, I rolled out my own class that accesses the Windows API directly. This work-around forces me to provide my own implementations for shared memory on all platforms I must support.

The real solution would be to be able to use Unreal’s FPlatformMemory::MapNamedSharedMemoryRegion() function to create my shared memory object. This function is still failing, but my own equivalent function (see my link to the github gist above) actually works. It’s completely bizarre and this has left some of my coworkers baffled.

If you want to reproduce what I’m seeing, step through the MapNamedSharedMemoryRegion() function on a Windows computer using the Visual Studio 2013 debugger.

Thank you.

I see, I’m looking into the issue further, but in the meantime, I believe that part of the issue may be related to this line:

LogHAL:Warning: CreateFileMapping(file=INVALID_HANDLE_VALUE, security=NULL, protect=0x4, MaxSizeHigh=0, MaxSizeLow=262168, name='Global\MySharedMemory') failed with GetLastError() = 5

Specifically, the part where it says that ‘security=NULL’. This being null could be causing you to have issues accessing due to a lack of credentials.

I think the cause of the problem comes from the ‘Global’ prefix the Unreal Engine code applies to all shared memory names. According to msdn, creating a global shared memory object requires some kind of special permission if you’re not in session zero. I have no idea what “session zero” means, but it must be causing security=NULL, like you pointed out.

Maybe the fix is to remove the ‘Global’ prefix in the Unreal Engine code? I think this is the fix because my code does not prefix the shared memory name with Global and it ends up working in my game.

Hi jgcoded,

I apologize for the time since my last post, unfortunately this isn’t a feature that the engine was designed to support and thus I am not quite able provide more information as to how to integrate this feature. If you believe that removing the Global prefix in the source code would fix this issue, I would suggest making a Pull Request on our GitHub page (.com/EpicGames/UnrealEngine) so that it can be reviewed and possibly integrated into a future build.

Have a nice day,

Thanks for your response