Jump to content
  • Application Error dialog box appears on start, then closes application immediately.


    Pysis
    • Status: Not a bug
      Main Category: Core / Mangos Daemon
      Sub-Category: Core Crash
      Version: 21.14 Milestone: Unset Priority: New
      Implemented Version: Unset

    Update/TLDR: Don't add another app on your PATH that may add a library, like OpenSSL's libeay32.dll.  Also don't use a too recent version of OpenSSL like version 1.1.1, instead use most recent LTS version 1.0.2.  Also please document this detail more as it is more difficult without practice to debug application loading issues O_o.

    -----------------------------------------------------------------------------------------------------------

    Unable to search the bug tracker by summary text or keywords.

    Occurs for both "realmd.exe" and "mangos.exe".

    Opens dialog stating above and error code (0xc000007b), closing immediately after I click ok.  Doing so plainly from file explorer causes this issue.  Invoking it from a CLI simply returns with no messages printed.  I don't see anything in Windows Event Viewer for this error, which is a bit surprising.  Would like a log file to inspect, but maybe this error occurs too early in the processes boot process.

    I wanted to debug in Visual Studio but only got a list of loaded dlls, no breakpoint in the disassembly as I was hoping.  I don't have the source code set-up for it.

    I tried looking at dependencies like either of the provided MSVC++ 2015 14.0... redists and it said I have that or newer versions already installed.

    Installed Win64 OpenSSL v1.1.1g 63MB Installer from https://slproweb.com/products/Win32OpenSSL.html which made libssl-1_1-x64.dll appear in System32 where it was not before, still have the error.  Same even when copying those files to the program's same directory.  I even followed this guide to set environment variables without any better result: https://tecadmin.net/install-openssl-on-windows/

    Looking at links like these:

    https://appuals.com/fix-error-0xc00007b-application-was-unable-to-start-correctly/

    https://www.diskgenius.com/how-to/fix-error-code-0xc000007b.php

    https://www.reviversoft.com/blog/2013/11/how-to-solve-the-0xc000007b-unable-to-start-error/

    https://answers.microsoft.com/en-us/windows/forum/windows_other-gaming/unable-to-start-correctly0c000007b/d454167c-3fb9-47c2-bc1b-e66c7146211b?auth=1

    I have tried running as administrator, making sure I already had the optional windows feature MS .NET Framework 3.5 (with 2.0 and 3.0) (half) selected/installed, and seeing that I had "xinput1_3.dll" files in the System32 and "SYSWOW64" directories, 64-bit and 32-bit respectively.

    I am using server_releasex64 0.22.0 downloaded recently from GitHub.  Didn't know how to select that for the bug's Version field.

    Both of the exe files are "PE32+ executable (console) x86-64, for MS Windows".  Same arch for the included mysql client dll, version 5.7, and also for the recently (re-)installed openssl dll.

    On my Windows 10 64-bit system, fresh install with game data extracted and database data initialized, running MySQL 8.0.19 Community Server Win64 (x86_64) and 5.7 as well, although I don't think that's relevant for this application boot issue.

    Seems I have the same issue Xemron had in the getMaNGOS Public discord server #help-and-support channel on 01/08/2019: https://discordapp.com/channels/286167585270005763/429648020875771904/532374732096405512.

    -------------------------------------------------------------------------

    Somehow I managed to think of more tools to use to debug this issue.  I thought Sysinternals Process Explorer (Procexp) letting me view open handles for the process would help locate the loading issues, bit it didn't list many at all.  Then I went onto Process Monitor (Procmon), found some interesting entries, filter by filesystem and/or process/thread activity, did an export, ran a shell command:

    Quote

    cat "$file" | tail -n +2 | cut -f5 -d',' | sed -r 's|^"([^"]*?)"$|\1|g' | grep -E '\.dll$' | sort | uniq | while read file; test -e (cygpath "$file"); and file "$file"; end

    and guess what I found.

    It was trying to access a "libeay32.dll" it wanted anywhere, and finally found it in an nmap installation I had previously put on my path, and it was 32-bits, mixed with my 64-bit system and other loaded dll files, similar, but not exactly what those other articles were mentioning.

    I wonder why the OpenSSL I had didn't work, but after viewing this link:

    https://github.com/sfackler/rust-openssl/issues/448

    I got an idea that it was the correct provider.  Then I revisited this article:

    and found a little comment in there talking about not using the latest 1.1.1 version as an incompatibility, but the 1.0.2 promised LTS release of the library.  Once I installed that distribution I was good to go :).

     

     

    With this process, I believe it would be useful to highlight that comment more in several places.  In the main content of that one guide, on the GitHub repo readme file, and possibly elsewhere.

    Related Posts:

     

    Loaded DLLs.txt

    Loaded DLLs 2.txt


    User Feedback

    Recommended Comments

    There are no comments to display.



    Guest
    This is now closed for further comments

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use