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/comm...bb52c418f72bd8


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 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.