[RMP 10.3.1] [INtime 6.4.21125.2]
The MS linker supports a flag, /DELAYLOAD:<binary>
I would like to leverage this behavior WRT RapidCode.dll so that my application (a plugin for another application that I do not maintain) won’t attempt to load the DLL (and its dependents) unless I actually need to. If my plugin is not enabled, I don’t want to load things. If it gets loaded on a system where it won’t work, I would prefer not to load things. I also want to be able to add directories to the search list for DLLs without requiring that all the dependent DLLs not be in PATH or copied to the CWD.
Knowing when to load is all defined by me. Updating the search path is on me.
My question for you is, do you have any advice regarding this scenario?
What I’ve Done
- I added
/DELAYLOAD:RapidCode.dll
to the linker command line for my project. - I added
%RSI%\x86
and\path\to\intime\bin
to the DLL search path.
Loading things this way works fine. I can run and do all the same stuff I could do before I added delayed loading.
However, when the application shuts down, I’m getting crashes inside ntx.dll
. Here’s what WinDBG reports as the stack trace.
> kv
008ff998 7ff026c0 00000000 8939ee7d 7ff02534 ntx!_ntxRegSetValueExW+0x3936
008ff9d0 7ff0259a 00000000 008ff9fc 77ec2976 ntx!SetLastNtxError+0x1194
008ff9dc 77ec2976 7ff00000 00000000 00000001 ntx!SetLastNtxError+0x106e
008ff9fc 77e9dd22 7ff02534 7ff00000 00000000 ntdll!LdrxCallInitRoutine+0x16
008ffa48 77ead7c5 00000000 00000001 c0d1899d ntdll!LdrpCallInitRoutine+0x51 (FPO: [Non-Fpo])
008ffae0 77ead6b5 00000000 00000000 007b9000 ntdll!LdrShutdownProcess+0xf5 (FPO: [SEH])
008ffbb0 76204112 00000000 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0xb5 (FPO: [Non-Fpo])
008ffbc4 7728451c 00000000 00000000 772843f0 KERNEL32!ExitProcessImplementation+0x12 (FPO: [1,0,0])
008ffbd0 772843f0 00000000 008ffbf0 008ffc00 ucrtbase!exit_or_terminate_process+0x20 (FPO: [0,0,4])
008ffbf8 77284391 00000000 008ffc44 038105a1 ucrtbase!common_exit+0x5c (FPO: [Non-Fpo])
...
By this time in the life of the application, all my stuff has been cleaned up. (For the sake of argument, let’s say I did it all correctly.) There are no other threads running. There shouldn’t be anything using resources within that module.
What’s up with the crash?
Do you have any idea what INtime’s DLL is doing?
The (possible) parameters to the called functions don’t obviously mean anything to me.
Is there some sort of cleanup that might get INtime not to do whatever it’s doing?
Ideas?
- I’ve tried manually unloading both
RapidCode.dll
andntx.dll
in the very last bit of code that runs in my plugin. - I added a breakpoint at this point and manually/forcibly unloaded
ntx.dll
in the debugger.- This crashed, unsurprisingly, when some kernel function tried to execute code within the module’s former address space.
- I considered switching
ntx.dll
to being delay loaded, but in order for that to work, I actually have to link against it. I don’t have an import library (though I can easily create one), and what’s worse, I don’t have a header file.