locked
64 bit Compile. Missing statically linked 64 bit DLL generates a fault after general "Missing DLL" popup RRS feed

  • Question

  • With a 64 bit Compile, testing when a required  64 bit DLL is missing, statically linked,  we get the normal windows "Missing DLL" popup, but then a fault is generated in NTDLL.DLL and you get the windows error reporting windows prompts .

    How can I prevent this?  I disabled all windows error reporting in the compiler/linker configuration.  I just want the normal missing file popup by the OS?  

    Thanks

    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com

    Wednesday, April 3, 2019 4:11 PM

All replies

  • It doesn't happen here. I just get the missing DLL message.

    Have you tried the same test on multiple computers?


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Marked as answer by hector santos Wednesday, April 3, 2019 4:54 PM
    • Unmarked as answer by hector santos Thursday, April 4, 2019 1:43 PM
    Wednesday, April 3, 2019 4:26 PM
  • I went out to lunch when I posted. I was thinking to test other OSes on my ride back.  I develop on Win2012 server with the missing DLL ntdll.dll fault. ....

    on Windows 7, its ok. 
    on Windows 10, its ok.

    Ok, that's enough to suggest its the OS, Windows Server 2012 (R2 Standard), I never updated it... arggggggggg.  Unless there is a specific known fix/patch to get, probably not worth it, I hate getting all additional overhead and stuff from MS, overloading my main development box.

    Oh well thanks.  I will make your post as the answer.  :)


    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com




    Wednesday, April 3, 2019 4:54 PM
  • Performing updates now.  3-4 years worth of patches, I had a KB roll up done in 2016!  Hope my machine doesn't break!! <g>


    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com


    Wednesday, April 3, 2019 6:42 PM
  • Hi Hector,

    Welcome to the MSDN forum.

    We are glad to hear that your issue is solved and thanks for Darran's suggestion.

    If you have any other issues in the future, please feel free to let us know.

    Best regards,

    Sara 


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Thursday, April 4, 2019 1:46 AM
  • Issue is not solved.  I updated Windows 2012 to the latest versions/updates.  And the issue is still there and I determined it is also under 32 bit.

    My statically linked DLL, when not found, the Windows OS popups the normal missing file/module error, and when you click OK, a GPF occurs with WER popping up.  This is the problem signature:

    Problem signature:
      Problem Event Name:	APPCRASH
      Application Name:	wcc.exe
      Application Version:	8.0.454.8
      Application Timestamp:	5ca50cbe
      Fault Module Name:	wccdll64.dll
      Fault Module Version:	6.3.9600.19304
      Fault Module Timestamp:	5c7f684f
      Exception Code:	c0000135
      Exception Offset:	00000000000ecf30
      OS Version:	6.3.9600.2.0.0.272.7
      Locale ID:	1033
      Additional Information 1:	ac05
      Additional Information 2:	ac0507478d1c5bd693cfc4fe3987e900
      Additional Information 3:	ac05
      Additional Information 4:	ac0507478d1c5bd693cfc4fe3987e900
    

    I just ran this release build under VS2015 debugger which starts a copy of the built exe where the required DLL is not located and no where on the path.  The expected Windows Missing File pops up and then after clicking OK, there is a GPF with:

    Unhandled exception at 0x00007FF86DE1CF30 (ntdll.dll) in wcc.exe: 0xC0000135: Unable to Locate DLL.

    If the EXE was dynamically linking the DLL, that would be a different thing and I could be able to control it.  I have another EXE which does load it dynamically, and a normal LoadLibrary() error 126 "module not found" is captured.

    But what I can do when its statically link to another app and the DLL is missing?

    Is there anything I can do programmatically or with the configuration?  

    Suggestions to look at?  Maybe a Delay Link?????   



       



    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com

    Thursday, April 4, 2019 2:25 AM
  • I have the current Windows 2012, updated.  

    I ran Depends and it gives me the following:

    Second chance exception 0xC0000135 (DLL Not Found) occurred in "NTDLL.DLL" at address 0x00007FF86DE1CF30.

    So there is an exception trap I can probably add, but how do you do that with a statically link DLL?

    Is there global exception callback function for the process I can prepare for when the OS NTDLL.DLL throws an exception?

    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com


    Thursday, April 4, 2019 3:24 AM
  • This appears to be a Windows 2012 Server R2 issue as I was able to repeat the problem with other 3rd party products and their required helper DLL file were missing, i.e. OpenSSLexe v1.0.2 (32 bit) and OpenSSL64.exe v1.1.1 (64 bit).  The only commonality here is all are compiled with VS2015.  But I would be hard press to believe it is a C/C++ VS2025 issue.

    The OS was fully updated yesterday using the OS "Check for Updates" app.  54 KBs were found and installed.




    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com


    Thursday, April 4, 2019 2:09 PM
  • Maybe configure it to be delay-loaded.  But its still a hack. (;

    • Edited by RLWA32 Thursday, April 4, 2019 2:28 PM
    Thursday, April 4, 2019 2:27 PM
  • Well, when you link to a dynamic library at compile time, the way that Windows does this hasn't changed since Windows NT 3.1 or Windows 95.

    What the compiler has always done is written entries into the Import Address Table (IAT). When you run an application, Windows will then iterate through the IAT looking for libraries to load, and when it finds entries in the IAT Windows will load that library.

    When the library is loaded, Windows will first load all dependencies, the library itself and then look in the libraries Export Address Table (EAT) for the addresses of the exported functions. The loader then takes the addresses that the executable/DLL needs and then writes these to the application's IAT.

    Since this is a contract that the compiler depends upon, it is not going to change.

    Anyway, as I should have implied in my first post, have you tested other copies of Server 2012 R2 or Windows 8.1? This is important because this will allow you to round down whether it is a general problem for this version of Windows, or if it is just your developer machine.

    After a while, these settings can get into a weird state, especially if your computer has bug checked (BSOD'd) at least once, so this could very much be an indicator that it is time to reimage your dev system.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Thursday, April 4, 2019 5:53 PM
  • Thanks for the IAT/EAT info. 

    No, I didn't try another Win2012. Good idea.  I don't I have another installed.  I can ask around.  Ok, I got someone creating a WIn2012 VM to test out.  In the mean time, not going to worry about it too much unless there is something fundamentally wrong with my DLLs.  I generally make all my DLLs with DLLMain() entry stuff, i.e, like calling DisableThreadLibraryCalls() but for this specific DLL it is not doing anything in DLLMain().

    Ok, Just got report from a VM Win2012 R2 Standard install.

    Same problem!!!

    He doesb't have my new stuff. He has the current installation of Wildcat! 32 bit, and I asked him to hide/rename our RPC Client API interface DLL, wcsrv2.dll and start one of the tools, wcLocal.exe.  He got the normal Missing Module/File/DLL box and then click OK to get the GPF report:

    Problem signature:
      Problem Event Name: APPCRASH
      Application Name: wcLocal.exe
      Application Version: 7.0.454.6
      Application Timestamp: 5bd21bf9
      Fault Module Name: wcsrv2.dll
      Fault Module Version: 6.3.9600.18233
      Fault Module Timestamp: 56bb4e1d
      Exception Code: c0000135
      Exception Offset: 0009d3c2
      OS Version: 6.3.9600.2.0.0.272.7
      Locale ID: 1033
      Additional Information 1: 1abe
      Additional Information 2: 1abee00edb3fc1158f9ad6f44f0f6be8
      Additional Information 3: 1abe
      Additional Information 4: 1abee00edb3fc1158f9ad6f44f0f6be8
    
    


    Ok, maybe the moderator can move/redirect/report this issue to the MS kernel folks to try to figure it out.  I can give them a copy of Wildcat! but it appears to happen with another app (OpenSSL) also recompiled with VS2015.   

    I don't see this as our problem and VS2015 problem.


    Thanks



    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com



    Thursday, April 4, 2019 10:22 PM
  • Well, just to say, what happens in the DLL main of a DLL that is not found is irrelevant.

    The DllMain function is the entry point function for the DLL, so it has to be physically present within the DLL. What's more, since all function calls are made within the context of the DLL, the DLL's IAT, not the executable's IAT, is what is used to resolve addresses.

    This means that the order of events for when a module is loaded, this is the same regardless of if it is an executable or a DLL, is as follows.

    • All dependencies for the module are loaded
    • The module is loaded as I previously explained
    • The entry point of the module is looked up in the header and then called

    So the entry point function's (<entry point name>CRTStartup, i.e. DllMainCRTStartup or mainCRTStartup) is obtained from the executable header:

    OPTIONAL HEADER VALUES
                 20B magic # (PE32+)
               14.13 linker version
               75400 size of code
               38E00 size of initialized data
                   0 size of uninitialized data
               18290 entry point (0000000180018290)
                1000 base of code
           180000000 image base (0000000180000000 to 00000001800B2FFF)
                1000 section alignment
                 200 file alignment
               10.00 operating system version
               10.00 image version
               10.00 subsystem version
                   0 Win32 version
               B3000 size of image
                 400 size of headers
               BA1FB checksum
                   3 subsystem (Windows CUI)
                4160 DLL characteristics
                       High Entropy Virtual Addresses
                       Dynamic base
                       NX compatible
                       Control Flow Guard

    The value you are looking for is the entry point entry in the optional header. This is obtained from dumpbin /headers. This calls your entry point function after doing initialisation.

    So the contents of the DllMain function only matters after the DLL has been loaded.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Friday, April 5, 2019 11:10 AM
  • Ahh, right, chicken/egg thing  No DLLMain entry if the DLL is missing, right?   I just winging it while waiting for the VM Win2012 tester.  :)    

    I've been using DumpBin /Headers to get the machine type to make sure what images are 32 or 64 bit:

    dumpbin /headers *.dll | findstr "Dump machine"

    I did want to ask regarding the NTDLL.PDB symbol file not available.  What is the proper symbol server to use?  I tried the various online articles and but I already had the Microsoft Symbol server in the Tools | Options |Debugger setup.   I saw something about "wntdll.pdb"  renamed???   

    Anyway, is this something you guys/moderator will kick off to the kernel/OS folks?  It appears to be a legitimate bug for them to check out.  

    Thanks


    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com



    Friday, April 5, 2019 1:58 PM
  • I use the Microsoft Symbol Server, in Visual Studio I just click on the Microsoft Symbol Servers check box and it just works.

    But for the 32 bit version of ntdll.dll, I suspect that it is built as wntdll.dll. If you look at the core system DLLs that communicate with kernel mode (ntdll, kernel32, kernelbase, user32, gdi32 and gdi32full) they all have the w in front of the name.

    My thought is that they are built with the w in front of the name but later renamed to the expected name to differentiate these from the native DLLs during build. You see, they are the libraries that would communicate with the kernel but the 32 bit libraries probably can't communicate with the kernel directly. Because of this, these DLLs are part of the WoW (Windows on Windows) layer and would communicate with the kernel using the 64 bit versions of these libraries or some other packaging mechanism as a proxy.

    So the wntdll.pdb file contains the debug symbols for the 32 bit library.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Friday, April 5, 2019 5:23 PM
  • Thanks for the good info.

    Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com

    Sunday, April 7, 2019 3:03 AM