Post subject: N64 load error
Joined: 8/18/2015
Posts: 8
Hey, seem to be having a problem running Bizhawk 1.11.1 on Windows 8.1 (x64). Whenever I try to load an N64 game, it gives me this error. I can confirm that the plugins are located in the dll folder inside of the Bizhawk folder. Despite renaming/redownloading there has been no changes. I have also found another user had a similar problem but never listed how to fix it. If I could get some assistance that would be amazing.
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
link please
Joined: 8/18/2015
Posts: 8
Sure, forgot to post it in the original post so here; http://tasvideos.org/forum/viewtopic.php?t=16254
Joined: 8/3/2009
Posts: 158
If it was a path problem, then just enter the path options and make sure you manually select the folder that plugin is at.
Joined: 8/18/2015
Posts: 8
Alright, I've tried to manually set the paths as seen in this screenshot. But I'm still having the same problem. As well as changing the paths specifically in the N64 tab. Still no change, I can record these instead of taking a screenshot if it helps you guys?
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
What "plugins" are located in the dll folder? Did you manually put anything there? All your fooling around in the path configuration isn't going to solve anything. But it was helpful in answering another question I have, which directory is your bizhawk based in. There seems to be nothing unusual about that. Since the other thread was about the same error message, maybe you could try some of my debugging from the other thread:
zeromus wrote:
could be security software interfere with the file loading. try turning all that off. Make sure the file size is 8,704 bytes. try opening it in http://www.dependencywalker.com/ to see if it can load OK on your system outside of bizhawk.
did you run the prerequisite installer?
Joined: 8/18/2015
Posts: 8
zeromus wrote:
What "plugins" are located in the dll folder? Did you manually put anything there?
Just the basic plugins that came with Bizhawk. Vanilla install.
zeromus wrote:
All your fooling around in the path configuration isn't going to solve anything. But it was helpful in answering another question I have, which directory is your bizhawk based in. There seems to be nothing unusual about that.
Yep, just decided to follow the advice of another user. Plus it's easy to reset if I choose to do so.
zeromus wrote:
Since the other thread was about the same error message, maybe you could try some of my debugging from the other thread:
These are the errors I'm getting, hopefully it helps.
zeromus wrote:
did you run the prerequisite installer?
Yep, I've installed the prerequisite installer already as well.
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
Try pasting all the dlls from the dll directory into the same directory as emuhawk.exe. You may have heard a lot of people suggesting this, but it isn't as effective as they think. Nonetheless, it may work in this case. You're not supposed to have to do that obviously. If that fixes it, maybe we can find out why it fixes it. It's odd though, the video plugin is loaded first. If it couldnt find the plugin dlls, then youd think it would fail on the video plugin first, so I'm not confident. The audio plugin seems to be very lightweight, why would it be the one that fails? It's practically nothing at all. Also try running bizhawk from a directory on your desktop
Joined: 8/18/2015
Posts: 8
zeromus wrote:
Try pasting all the dlls from the dll directory into the same directory as emuhawk.exe. You may have heard a lot of people suggesting this, but it isn't as effective as they think. Nonetheless, it may work in this case. You're not supposed to have to do that obviously. If that fixes it, maybe we can find out why it fixes it. It's odd though, the video plugin is loaded first. If it couldnt find the plugin dlls, then youd think it would fail on the video plugin first, so I'm not confident. The audio plugin seems to be very lightweight, why would it be the one that fails? It's practically nothing at all. Also try running bizhawk from a directory on your desktop
Alright, some progress! Seems pasting the dll's to the base directory seems to fixed the problem. Quite weird considering that I tried a few other games to see if it was just an issue reading from the dll folder, but they all worked fine. Just the N64 part of BizHawk wasn't cooperating If you want to try to figure out why this is happening, I'll keep an eye on this thread.
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
Try it again copying only the audio plugin, and then whichever other dlls it can't find, one by one, so we can discover whether there's something peculiar about the audio dll, or all the plugin dlls, or what
Joined: 8/18/2015
Posts: 8
Okay, so here's what has happened so far. Got a fresh install of BizHawk to make things easier. Copied the mupen64plus-audio-bkm.dll file to the base folder. Copied the mupen64plus-input-bkm.dll file to the base folder. Finally the mupen64plus-rsp-hle.dll file to the base folder. Which results in the game loading. It seems to be those three plugins not loading properly for some reason.
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
try loading a gbc and a gba game, just as a test of other dlls we've built. genesis, psx, and nes (change core to quickNES) too. maybe we can find a pattern. the N64 video plugins we built too, but I have no clue why those work. Make sure you tried all the n64 video plugins as well. try running getting process monitor and running it to watch for accesses to "path contains -bkm" to see if the wrong path is getting searched, or whether it's getting searched and the file is even getting open but the dll loading is failing at some later point try deleting your 4 files c:\windows\system32\msvcr100.dll c:\windows\system32\msvcp100.dll c:\windows\syswow64\msvcr100.dll c:\windows\syswow64\msvcp100.dll and then rerunning the prerequsite installer
Joined: 8/18/2015
Posts: 8
Alright, so I've tested almost everything supported in the official release of BizHawk. Everything seems to work fine. The few I didn't get to test was the Sega Saturn, the TI-83 and the Atari Lynx. The different N64 plugins all work fine, no problems found there. Process Monitor reported this, when using a vanilla install; After some work, finally managed to delete the files you asked to get rid of. I then ran the prerequisite installer, which went through without a problem. I then get this error. I've tried to restart the computer to see if that fixed it, no luck. This broke both the working and vanilla BizHawk.
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
ok, so, clearly something jacked up on your system changed the dll directory in our process. We've seen that happen to a limited capacity with intel gpu drivers, but you seem to be running nvidia so it must be different. There's some things we might could do wrestle against that in our code, but it won't work in every case (though it may work in this case). It'd be better if we could find out what's screwing up the dll directory. You could do this by killing processes one by one, and then running emuhawk, and eventually you might find the problem goes away. Of course, you can't do that if you can't even run emuhawk at all anymore. You could fix that of course by undeleting the dlls. We've seen slimdx fail in this way on account of having nonsense msvcr100.dll installed (by what?? we don't know yet.) the prerequisite installer won't overwrite the dlls if they're there, but you had just deleted them, so... I'm baffled. If it's the same problem with slimdx.dll we've seen before, then you have a 64bit msvcr100.dll installed in the syswow64 directory (it should be 32bit). We can check that by copying it OUT of the windows directory, and then loading it in dependency walker (which will say whether it's 64bit). Maybe something's interfering with the prerequisite installer. I'm sure I can sort all this out if you get on IRC and negotiate with me for a chance to teamviewer to your PC, but since you know the workaround, I wouldnt blame you if you lost interest. Still, I'd like to debug it while I can.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
zeromus wrote:
We've seen slimdx fail in this way on account of having nonsense msvcr100.dll installed
Can BizHawk be compiled statically, i.e. without relying on these runtime DLLs?
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
creaothceann wrote:
zeromus wrote:
We've seen slimdx fail in this way on account of having nonsense msvcr100.dll installed
Can BizHawk be compiled statically, i.e. without relying on these runtime DLLs?
no
Joined: 8/18/2015
Posts: 8
Sure, I'm up for it. I'll be in the IRC under TB.
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
Well, that was quite a rabbit hole. Looks like the system vendor was only providing outdated intel drivers. Outdated intel drivers call SetDllDirectory at various intervals when direct3d8 is used, and at various lesser intervals when direct3d9 is used. Jabo was enabled for N64 by default; it was activating the d3d8 and screwing up the dll redirection. Forcing the system to accept newer intel-provided drivers fixed the problem. Additionally, I'll checkin a fix which tries to repair the DLL redirection around the sites where the old intel driver munges it. This may still be important, since some systems can't upgrade their drivers as readily as we saw here (especially, older GPU models won't have had newer drivers ever issued) Regarding slimdx.dll, somehow the user's mscvcr100.dll got straightened out and the problem disappeared. We'll have to debug that some other time. For the record, here's a driver version that doesn't work: (windows 8.1) Intel HD Graphics 4600 10.18.10.3308 - 9/16/2013 and one that does: (windows 8.1) Intel HD graphics 4600 10.18.14.4251 - 7/7/2015
Editor
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
zeromus wrote:
Well, that was quite a rabbit hole. Looks like the system vendor was only providing outdated intel drivers. Outdated intel drivers call SetDllDirectory at various intervals when direct3d8 is used, and at various lesser intervals when direct3d9 is used. Jabo was enabled for N64 by default; it was activating the d3d8 and screwing up the dll redirection.
I have done quite a bit of tech support myself, but this, is the winner for Most Odd Ball Thing, I have ever heard of.
When TAS does Quake 1, SDA will declare war. The Prince doth arrive he doth please.