Closed eur0pa closed 9 years ago
Did you try running 1.2.4 more than once? It continuously gave that error? What OS/Anti-virus combo are you using?
That's an internal library error for boost::interprocess which shouldn't really happen so I need more info to know why MHUD2 crashes with that.
It works well. I use Win10/Kaspersky and I have not encountered any bug. PS. Please ignore my broken English
It's now working properly after ~24 hours and a couple of reboots. Let's see what the issue was:
I'm not an "average user" so my environment is pretty clean and taken care of. While now it's working properly, I'm still baffled on how it couldn't yesterday — in fact, I'm going to try and understand why that happened. I'll let you know.
boost::interprocess uses this registry key on a 64-bit system to work out where to save the interprocess memory: HKLM\Software\Wow6432Node\MicrosoftWindows\CurrentVersion\Explorer\Shell Folders\Common AppData
By the GetLastError() code you got (183 == ERROR_ALREADY_EXISTS) maybe there was something corrupting the file it was supposed to create in that folder? I honestly have very little idea, I never ran into that error on my main dev machine nor any VM's I tested it on.
I'm glad it's fixed now at least!
I was able to reproduce the issue by deleting the '1444982038' folder in C:\ProgramData\boost_interprocess and restarting MHUD2 and the game. While MHUD2 will create the boost_interprocess directory, it won't create the needed file and folder in order to communicate with the main process. Maybe a permissions issue? Restarting it and trying again won't fix it — the folder is still missing. I'll reboot and edit this comment after running a few tests.
edit: rebooting the machine, launching MHUD2 and then running the game fixed it again: the '1444988429' folder was created inside C:\ProgramData\boost_interprocess:
16/10/2015 11:35 <DIR> europa-pc\europa boost_interprocess // created before the reboot
...
C:\ProgramData\boost_interprocess>dir /n /q /r /tc
Volume in drive C has no label.
Volume Serial Number is C4F5-8657
Directory of C:\ProgramData\boost_interprocess
16/10/2015 11:35 <DIR> europa-pc\europa .
16/10/2015 11:35 <DIR> NT AUTHORITY\SYSTEM ..
16/10/2015 11:45 <DIR> europa-pc\europa 1444988429 // created after the reboot
0 File(s) 0 bytes
3 Dir(s) 74.948.177.920 bytes free
C:\ProgramData\boost_interprocess>icacls *
1444988429 No permissions are set. All users have full control.
Successfully processed 1 files; Failed processing 0 files
...
C:\ProgramData\boost_interprocess\1444988429>dir /n /q /r /tc
Volume in drive C has no label.
Volume Serial Number is C4F5-8657
Directory of C:\ProgramData\boost_interprocess\1444988429
16/10/2015 11:45 <DIR> europa-pc\europa .
16/10/2015 11:45 <DIR> europa-pc\europa ..
16/10/2015 11:45 52.064 europa-pc\europa mhud2_msg_queue //
1 File(s) 52.064 bytes
2 Dir(s) 74.948.177.920 bytes free
C:\ProgramData\boost_interprocess\1444988429>icacls *
mhud2_msg_queue europa-pc\europa:(F)
NT AUTHORITY\SYSTEM:(F)
S-1-5-5-0-1127979:(RX)
It can't be a permissions thing, otherwise boost::interprocess would never work on your system (the directory permissions won't randomly change on a reboot).
According to boost:
This directory name is the last bootup time obtained via COM calls (if BOOST_INTERPROCESS_BOOTSTAMP_IS_LASTBOOTUPTIME is defined) or searching the system log for a startup event (the default implementation)
If using the default implementation, and the Startup Event is not found, this might be due to some buggy software that floods or erases the event log.
That could be why? Obviously on a reboot your system log would be cleared, so it can once again find the startup event. Nevertheless, I think for the Afterbirth version of MHUD2 I will just tell boost::interprocess to use the non-default implementation (COM calls) to avoid this (unlikely) error.
If that doesn't fix it then my hands are tied anyway because I'm not familiar enough with the internal implementation of boost::interprocess to be able to debug it without being able to replicate the issue in a debugger myself.
Thanks for your detailed issue report though, it makes things much easier!
Alright then. I can consider this issue fixed; maybe add a footnote to the readme stating that in case of similar issues a reboot is definitely likely to fix it.
Thank you
I want to add that the culprit is CCleaner with an aggressive WinApp2.ini. Adding C:\ProgramData\boost_interprocess to the exclude list stops the issue from arising.
Ah, you know that seems non-ideal on their part because that will cause issues with any app that uses boost::interprocess. It's not a massively popular library, sure, but still. It's definitely not unknown.