0

Background:

I am writing a app using an open source library. This open source libarary comes with many plugin dlls. Some of which we are using in our project (NOT all of them).

While in developement, we just consumed the library as a whole and everything worked fine.

Now when we are trying to build a shippable binary package, seems like we need to sort things out and find only those plugin binaries (dlls) from the open source lib which are in use.

These library comes with 100 of plugin dlls. During runtime, we just using a primary lib plugin dlls, which in turn loads up other dlls (Curently when we run the App, it loads both essential or non-essential dlls). We need to find out a way how to only pack those dlls which we are using in the code. And since these are plugins only, if the primary dll don't finds the non-essential dlls, then it is completely fine (App won't crash). We just have to help it locate the essential ones (without that pur either won't work or will crash).

Approach: In order to find only the essential dlls, what I have done is removed all the dlls from the path and started placing one dlls each time to check, until our App start working. The problem is that with this approach it is going to take a long time. Rather than randomly picking each dlls I trying to use WinDbg to find out which missing dlls has caused the failure.

Question: Is there a way in Windbg to identify from a dump, to see which missing dll has caused failure?

kishoredbn
  • 2,007
  • 4
  • 28
  • 47
  • If the only problem is that your program failed because the user's machine had a DLL missing then you should *never* have to rely on WinDbg. That's a completely normal mishap, nothing you can do yourself to teleport a file onto that machine. So you must generate a good diagnostic for the user so they can fix it. Without it, that problem is hard to diagnose for you as well. Harder. – Hans Passant Oct 08 '20 at 22:22
  • 1
    Process Monitor can be a more suitable tool here, as it shows you what files a program tries to read. Don't make things over complicated. – Lex Li Oct 09 '20 at 03:20
  • @LexLi ProcMon doesn't help. The open source lib tries loading all the plugin dll as soon as it loads. It loads everything, so it is hard to figure out which among them is used in the later part in the app. – kishoredbn Oct 09 '20 at 03:47
  • Then a code coverage tool might help, as it tells which libraries/methods are called. – Lex Li Oct 09 '20 at 05:46
  • [Show loader snaps](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/show-loader-snaps). – IInspectable Oct 09 '20 at 07:46
  • Ldr snaps are for live debugging I think op wants to know of a lib load failure in dmp if I read the post correctly – blabb Oct 09 '20 at 10:26
  • you can use ETW to record image load events + Stacks to see how the DLL gets loaded. [In my profile](https://stackoverflow.com/a/30289933/1466046) without taking dumps. I have ImageLoad/Unload events and exception logging included. it should help you – magicandre1981 Oct 10 '20 at 06:25
  • @kishoredbn: ProcMon will help. I'm 98% sure.If not, you don't know how to use it correctly. It's not possible with WinDbg. – Thomas Weller Oct 10 '20 at 17:30

1 Answers1

0

Your Question As it Appears is Ambiguous.
Most of commenters have provided you hints For a live Debugging Session Like.

  1. Ldr Snaps
  2. ProcMon
  3. Etw Traces

you seem to have asked For looking at it in a dump

Question: Is there a way in Windbg to identify from a dump, to see which missing dll has caused failure?

a plugin by its nature will be allowed to fail gracefully By its Parent Binary and as such it will Create an Unload Event

This Will Be reflected in the dump by lm Command
the Unloaded Modules will be listed at the end of Module List

:\>cdb -c "lm;q" -z c:\odbgdmp.dmp |awk "/Unloaded/,/quit/"
Unloaded modules:
66940000 66957000   OllyDumpEx_Imm17.dll
quit:

ntdll maintains an array 0x40 last unloaded dlls windbg Retrieves this from the same place as the below code does.

#include <stdio.h>
#include <windows.h>
typedef struct _RTL_UNLOAD_EVENT_TRACE {
    PVOID BaseAddress;SIZE_T SizeOfImage;ULONG Sequence;ULONG TimeDateStamp;
    ULONG CheckSum;WCHAR ImageName[32];
} RTL_UNLOAD_EVENT_TRACE, *PRTL_UNLOAD_EVENT_TRACE; 

typedef VOID (WINAPI* RtlGetUnloadEventTraceEx) (
_Out_ PULONG *ElementSize,_Out_ PULONG *ElementCount,_Out_ PVOID  *EventTrace
);

RtlGetUnloadEventTraceEx evt;

int main(void) {
    //ollydbg plugin wont load in curproc will create an unloaded mod event
    LoadLibraryA("OllyDumpEx_Od20.dll");
    HMODULE nt=LoadLibraryA("ntdll.dll");
    if(nt != NULL){
        evt=(RtlGetUnloadEventTraceEx)GetProcAddress(nt,
        "RtlGetUnloadEventTraceEx");
        PULONG  elsiz = NULL, elcnt = NULL;PVOID evarr = NULL;
        evt(&elsiz,&elcnt,&evarr);
        printf("%p %p %p\n" , elsiz,elcnt,evarr);
        printf("%x %x %x\n" , *elsiz,*elcnt,*(int*)evarr);
        PRTL_UNLOAD_EVENT_TRACE u1=((PRTL_UNLOAD_EVENT_TRACE)(*(int*)evarr));
        printf("bas\t%p\nsiz\t%x\nSeq\t%x\nstamp\t%x\nCsum\t%x\nname\t%S\n",
        u1->BaseAddress,u1->SizeOfImage,u1->Sequence,u1->TimeDateStamp,
        u1->CheckSum,u1->ImageName);        
    }
    return 0;
}

on executing

:\>UnloadModList.exe
7706CDA0 7706CD9C 77067144
5c 40 1fafd8
base    676F0000
size    19000
Seq     0
stamp   55953f77
Chksum  12b14
imgname OllyDumpEx_Od20.dll

corroboration of dll details which failed to load

:\>dumpbin /headers OllyDumpEx_Od20.dll | grep -iE "CheckSum|Stamp|size of image|image base"
        55953F77 time date stamp Thu Jul  2 19:11:11 2015
        6A680000 image base (6A680000 to 6A698FFF)
           19000 size of image
           12B14 checksum
blabb
  • 8,674
  • 1
  • 18
  • 27