https://itm4n.github.io/windows-dll-hijacking-clarified/
This explains better but Dependency Walker only checks if DLL is the import table. At runime a program can use LoadLibrary() to call other dlls. I looked through all the DLL from DepWalker that Crystal uses, but didnt see one that was "wbem" or "wmi" sounding...
I tried replacing the 4 WMI related DLLs that Crystal needs into the windows sys folder. Dependency wise there was no issues, but Crystal still crashed.
In IDA, there is a "Suspended on Library load/unload". Running it, it looks like ntdll.dll is where wbmprox first loads, but a bunch of other DLLs load in that same spot is how it looked to me in IDA. No idea how to look up where it was in ntdll.dll itself...
Sumbled upon a "debug" setting that can be turned on in Crystal's ini. In there, the last entry before failure was "CMD_TYPE_NVME_INTEL". Opening up DiskInfo.exe, subroutine was findable with that name. A lot of IdentifyDevice, AddDevice calls, most ending up at a block with many inputs (all the Info/Add Devices Intel/Samsung/etc...) just before sub exits. Adding a breakpoint, it looks like Crystal gets through the NVME_INTEL block, and errors out at the MultiBlock.. Jumped out @4cf96 74 -> EB to skip "AddDiskNVMe - CMD_TYPE_NVME_INTEL". CDI starts at least, but nvme does not show up. Then tried skiping "DoIdentifyDeviceNVMeIntel" which calls ""AddDiskNVMe - CMD_TYPE_NVME_INTEL" @4ced8 74 77 -> 90 90 @4cf4b 0F 85 0A 01 00 00 -> E9 0B 01 00 00 90. Same things starts, but no nvme.
00001110 DoIdentifyDeviceNVMeStorageQuery
00001110 DoIdentifyDeviceNVMeIntelRst
00001110 DoIdentifyDeviceNVMeSamsung
00001110 DoIdentifyDeviceNVMeIntel
00001110 AddDiskNVMe - CMD_TYPE_NVME_INTEL
Looked further up the logfile. Compared one with wbemprox removed to a normal one.
no wbem / works
00000000 dlg.DoModal()
00000015 InitAta
00000015 CAtaSmart::Init WMI on - Start
00000015 CoInitializeSecurity()
00000031 CoCreateInstance()
00000031 NG:WMI Init 1
wbem / fails
00000016 dlg.DoModal()
00000032 InitAta
00000032 CAtaSmart::Init WMI on - Start
00000032 CoInitializeSecurity()
00000032 CoCreateInstance()
00000032 ConnectServer()
00000032 CoSetProxyBlanket()
00000047 OK:WMI Init
00000782 OK:Win32_IDEController
00000813 OK:Win32_SCSIController
Searched around on on those keywords. ConnectServer() to a wmi server maybe? Ended up in two subroutines that sounded interesting. Saw "\\.\root\cimv2" which was familiar...
Borrowed a quick vbscript to try wmi. Breaking the path stops it from working.
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_Process" & _
" WHERE Name = 'cscript.exe'" & " OR Name = 'wscript.exe'",,48)
For Each objItem in colItems
Wscript.Echo "-------------------------------------------"
Wscript.Echo "CommandLine: " & objItem.CommandLine
Wscript.Echo "Name: " & objItem.Name
Next
So in DiskInfo32 or DiskInfo64, find where "\ \ . \ r o o t \ c i m v 2" is with hex editor and change it to something like "\ \ . \ r o o t \ n o w m i". 630069006D00760032 -> 6E006F0077006D0069
Then let DiskInfo handle the error of a missing wmi the same way as if wbemprox file was missing.