Runtime Error 0xC000007B

[Uleat]

Is (has) anyone else running into this issue when attempting to start their server binaries?

This started occurring after the change from 'mysqlclient.lib' to 'libmysql.lib' (static to dynamic linking.)


I understand what the error means..but, it only affects the compiled server binaries and not other 32-/64-bit applications on my system.


It did this on my old os install and well as on a fresh one.


Windows 7 Pro 64-bit SP1
Visual Studio 2013 with Update 5 (current..same issue with original vs12 install)


NOTE: All binaries are affected except for shared_memory.exe - which still functions (winsock-related, since it doesn't use networking?)

[N0ctrnl]

Not sure about Windows, but I sometimes have to clear the 'hotfix_' entry in my variables table. Might give that a try.

[Uleat]

This is crashing on loading, unfortunately.

Even the Visual Studio debugger can not run them...

[Burningsoul]

Uleat, I'm running W7 x64 - if you want to share your binaries I'll give it a spin. My source folder is quite outdated and I have to read up on all the changes before trying a fresh compile for the test.

[vithmiris]

Uleat, I'm receiving this with a fresh build since the fix for the login server was committed.

I was receiving the same error previously but figured it had to do with the login server project being broke.

This is running under Windows 7-64 (Server built as 32 bit).

Edit: All executables fail as well, except shared_memory.exe.

[Uleat]

Burningsoul, let me get back in touch with you on that..playing around with dependencies atm.

vithmiris, I'll do some more pre-loginserver fix testing to see what I get. Pretty sure it was there, like you said. (That testing was a week ago and my memory fails past a day or two...)

[vithmiris]

Thanks, let me know if you need any testing, I'm set to re-image the box back to pre-install state.

[Uleat]

Double-checked prior to the loginserver fix - definitely there!


The change that seems to have done it is this: https://github.com/EQEmu/Server/commit/f19648f615fd3c7214aabf04eebb52c418f72bd8


First run, you'll probably get the missing dll message..copying the libmysql.dll file from the dependency directory that the binaries are built on to the server
folder alleviates that.

But..something about that change is definitely wrecking something...


I've been through all of my build logs, compared working and non-working solution/project properties side-by-side...

Only things I can guess at are there's something with the libmysql build that win 7 doesn't like..or win 7/visual studio has an issue with its linker and isn't
complying with what path data it's receiving/reporting.

This is a runtime error and doesn't show up when compiling..only when executing the binary (speaking of executing...)


Vithmiris, yours is the first other report that I've seen surrounding this issue...

[joligario]

No issues with Win10, VS Express 2013.

[vithmiris]

I did have to move the .dll in to the main server directory as the OS couldn't find it.

I'll give it a spin under Windows 8 or 10 and see how it goes (funny as I was avoiding 8 / 10 to build the server on).

[joligario]

Yuck, don't use 8. I recommend 10 if you plan on upgrading.

[Uleat]

I traced something last night that is showing promise..I'll post back with the results.

[vithmiris]

Just setup from scratch on Windows 10; the libmysql.dll and zlib1.dll (this time) needed to be moved in to the main server directory.

Other than that we have an operating server - just logged in locally from a client.

Time to image!

Thanks again guys.

[Uleat]

That works :)


I just verified that my issue is due to a zlib1.dll reference...

Not sure why just yet..but, it's attached as a direct dependency to all of my compiled binaries.

And, of course, the first one it finds is a 64-bit version in my intel wifi directory - hence the 0xc000007b error...


SIDENOTE: Process Monitor (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) is an excellent tool for tracing failures like this when debugging tools don't provide enough information.

[Uleat]

Ok, one of the other dev's helped me get my system back up and going.


It does look like the use of libmysql.lib will require the use of a zlib1-type reference, x86 variety.

We'll keep this one on the things-to-do list for now, since the affected populace is essentially nil at this time..

..but, if more people start to experience this, we can move it up.

[Krran]

Old thread, but I experienced this error when attempting to to a clean install today on Win 7 64-bit. It was unclear to me what to do to correct this issue, other than updating the OS.

[Uleat]

Still a relevant issue :)


Make sure that your have zlib1.dll in your server directory.

There is an option in the update script to download the three required dlls.


In my case, I was compiling 32-bit binaries on win 7 64-bit.

The requirement for zlib1.dll came from switching the mysql libs from static to dynamic (circa. June/July 2015.)

Most cases, it would seem, just report that the dll is missing.

It sounds like something in your %path% also uses zlib1.dll (for me, it was my 64-bit wifi driver..hence the 0xc000007b build mismatch error..a pita to trace...)


If you're building 64-bit binaries, you may run into the reverse issue as I think the suggested zlib1 dll is 32-bit.


Post back if you're still having problems.


EDIT: (sic) btw, an OS update won't fix it :/

[Krran]

Thanks for the response.

Here is the sequence of how things have happened since I last posted, and added info for clarity (I hope):

1. Updated to Win 10 (this was before I read your message)
2. Rebuilt the server again, using Visual Studio 12, 64-bit (I used this version on my last update, around June 2014, without error)
3. Ran the EQEmu start script without errors and got to the update prompt
4. Made sure I had the zlib1.dll, lua51.dll, and libmysql.dll files in the server directory, downloaded using the update script
5. Ran only the DB and bot update scripts and was able to logon with a test character
6. I then ran all the updating options available in the update prompt (DB, emu exes, .dlls, etc) to try to get as current as possible
7. I then confirmed that eq_emu_config.xml and login.ini had the proper DB information needed, as I saw a note about this whizz by during the updates

After step 7 listed above, I am getting the following pop-ups when attempting to launch the server:
1. Shared_memory.,exe, ucs.exe, and zone.exe are all giving the 0xc000007b error
2. zone.exe is giving an error - "perl512.dll is missing" (it appears I have perl514 on my machine)

I tried logging in with my usual client anyway. I can get to the sever select screen, but the server is not listed. No big surprise there.

I suspect I updated something I shouldn't have, or one of the updates is conflicting with my current setup. That barely narrows it down, though.

Do you have any tips at this point?

Thanks again for the help :-)

[dpjaf4t]

....
2. Rebuilt the server again, using Visual Studio 12, 64-bit (I used this version on my last update, around June 2014, without error)
....
6. I then ran all the updating options available in the update prompt (DB, emu exes, .dlls, etc) to try to get as current as possible
....
I am getting the following pop-ups when attempting to launch the server:
....
2. zone.exe is giving an error - "perl512.dll is missing" (it appears I have perl514 on my machine)


I am thinking that in the "emu exes" that the eqemu_update script downloads, the binaries are hard-coded specifically to (Active)Perl 5.12, especially given that being Akkadius' favored version for EQEMU. But when you built your own binaries, the CMake script found your locally-installed perl version.

Not being mean, but: Why build your own server executables and then overwrite them with Akkadius' versions? One of those steps seems at best unnecessary, and at worst you end up with the conflicting dependencies.

[Krran]

I am thinking that in the "emu exes" that the eqemu_update script downloads, the binaries are hard-coded specifically to (Active)Perl 5.12, especially given that being Akkadius' favored version for EQEMU. But when you built your own binaries, the CMake script found your locally-installed perl version.

Not being mean, but: Why build your own server executables and then overwrite them with Akkadius' versions? One of those steps seems at best unnecessary, and at worst you end up with the conflicting dependencies.

I ran the exe updates basically because I barely know what I am doing, to be honest, even after 7ish years. It is a hurtle for me most times I try to update.

If the answer is that the emulator files that are downloaded from github are up to date, then I probably am doing unnecessary or counterproductive work and causing conflicts by selecting the option to retrieve the exe files in update script, like you mentioned.

Thanks for the direction in helping me get back up to date. I will go back and try not selecting this update option, and similar options, this time.

[Uleat]

I honestly can't help with Windows 10...

I know there are some issues and they do get addressed..but, there are enough differences that I would be guessing.

[Krran]

I think I got things worked out to where I am as far as some other people are at the moment as far as updates.

I followed what dpjaf4t said and I was able to login my characters. However, bots could not be loaded and my characters lost about 100AAs each that had already spent. I found a couple recent threads on these issues that don't seem to be 100% solved yet, as far as I can tell.

But, now I know what to do and not to do when I try to update again later.

Thanks again for the help. Sorry to kinda drag this thread of topic.

[fault]

Im getting that error with just zone.exe in windows server 2012. all dlls were fecthed with the update script and are in the directory

[provocating]

This is crashing on loading, unfortunately.


Yep and the hotfix problem is during load, at least on Linux. I know this specific issue was probably not the hotfix thing, but it does happen.

[Uleat]

Are you running 32-bit or 64-bit binaries?


I had a 2-part issue where the dll was missing AND it was finding it in another folder as 64-bit..took forever to diagnose...