networkMe / missinghud2

Binding of Isaac: Rebirth/Afterbirth Statistics HUD
Apache License 2.0
339 stars 54 forks source link

Not injecting anymore since 1.2.4 #8

Closed eur0pa closed 9 years ago

eur0pa commented 9 years ago
[2015-10-15 12:09:25,367] [TID: 524] [INFO ] ========== Missing HUD 2 v1.2.4 ==========
[2015-10-15 12:09:25,568] [TID: 524] [INFO ] Starting DLL injection monitor thread.
[2015-10-15 12:09:25,569] [TID: 196] [INFO ] BoI process found, time to inject...
[2015-10-15 12:09:25,579] [TID: 196] [ERROR] Interprocess communication error occured: boost::interprocess::intermodule_singleton initialization failed (Error Code: 183)
[2015-10-15 12:09:26,088] [TID: 524] [INFO ] GitHub reported no updates available.
[2015-10-15 12:09:26,879] [TID: 524] [INFO ] Missing HUD 2 exiting with exit code 0.
[2015-10-15 12:09:26,881] [TID: 524] [INFO ] Stopping DLL injection monitor thread.
networkMe commented 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.

Removable commented 9 years ago

It works well. I use Win10/Kaspersky and I have not encountered any bug. PS. Please ignore my broken English

eur0pa commented 9 years ago

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.

networkMe commented 9 years ago

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!

eur0pa commented 9 years ago

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)
networkMe commented 9 years ago

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!

eur0pa commented 9 years ago

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

eur0pa commented 9 years ago

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.

networkMe commented 9 years ago

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.