"86Box process did not initialize in time" when it actually does
DOCaCola opened this issue · 14 comments
I have just installed the 86BoxManager for the very first time. I have created a new VM entry and press "Start". I instantly (without any delay) get the message that the 86Box process did not initialize in time. I have also tried to increase the timeout to 20000ms without difference. The 86Box instance actually starts up fine at the same time. I am using the current 86Box optimized nightly build. I have used a clean 86Box installation and also tried to boot up a blank VM showing the same issue.
Screenshot
Try using the regular 86Box build (unoptimized). Also, what are your PC specs?
Currently i am using the optimized 86Box build (1841) for Skylake. I have a 8700k CPU@4.8Ghz, 32GB Ram, Windows 10 (1809)
I have now also tried to use the "Regular" build (1841) with the same result as described above.
Might be relevant: 86BoxManager is also asking me to kill the process after throwing above error. Which when confirmed it does just fine.
Yes, asking you to kill the process it thinks is taking too long to init is intended behaviour. And the reason why it thinks this is either because the WaitForInputIdle() call returns false, or the main window handle of the process remains 0. But I have no idea why either of these would happen under normal circumstances, unfortunately.
There doesn't seem to be any good way around this problem either. The window handle is needed to communicate with an 86Box.exe instance - without it, the Manager loses a significant part of its functionality. I'll look more into this soon and see what can be done.
EDIT: Well I found a possible solution to try. I'll prepare a special build for you in the coming days to test this. I did notice that your CPU clock is considerably high, so if my theory is correct then the problem just doesn't manifest on slower CPUs.
I got it working with a quick and dirty workaround. I have added a sleep before the WaitForInputIdle function.
vm.Pid = p.Id; Thread.Sleep(500); bool initSuccess = p.WaitForInputIdle(launchTimeout);
However it did not work with just a 100ms delay. I had to increase it further to around 500ms. I don't understand yet why. I don't think that the cpu clock is the perpetrator for that. At least not when we are looking at magnitudes in the millisecond range.
Try adding p.Refresh() between WaitForInputIdle() and the if clause that follows it (and ditch the sleep call of course). Let me know if that works too.
As far as the ms go, the process wil always need some time to init. On my machine it's about 600-700 ms.
No. p.Refresh didn't do the trick.
p.Start();
bool initSuccess = p.WaitForInputIdle(launchTimeout);
p.Refresh();
if (!p.MainWindowHandle.Equals(IntPtr.Zero) && initSuccess)
This did work though:
p.Start();
vm.Pid = p.Id;
bool initSuccess = false;
int remainingLaunchTimeout = launchTimeout;
while (remainingLaunchTimeout > 0)
{
Thread.Sleep(10);
remainingLaunchTimeout -= 10;
if (!p.MainWindowHandle.Equals(IntPtr.Zero))
{
initSuccess = true;
break;
}
}
if (initSuccess)
{
What if you try putting just p.Refresh() between vm.Pid = p.ID and p.WaitForInputIdle() ?
Your recommended code change also didn't fix the issue. But good news. It is not an issue with 86BM at all. The culprit is Actual Window Manager. It seems to have an effect on that very function. I have disabled it now and 86BM now seems to work as expected. As soon as i reenable it, the issue is back. Your original code is fine as it is.
Hopefully this helps someone else experiencing this issue. It is possible to create an exclusion for 86BM in Actual Window Manager and the issue should be gone.
Very well, thank you for getting to the bottom of this issue.
I'm having the same issue, but I don't have AWM installed, nor do I use it
I have posted code above which does not rely on WaitForInputIdle and essentially does the same thing. If other software causes this issue as well, it might be a good idea to push it into the main branch.
You might want to open a separate issue and reference this one. Otherwise you probably won't get any visiblity, as this one is already closed.
oh ok
btw. i am not the developer. So if you want to have your issue fixed, open a separate issue so it can be seen.
I knew that