depends.exe: System cannot find loads of DLLs

Hi everyone,

My driver fails to load with the following error: “Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39)”
I put “MyDriver1.sys” through depends.exe:

This is strange: I found MSRPC.sys residing in C:\Windows\system32\drivers\msrpc.sys.
I tried searching for the long-named ones with L1-1-0 etc. with a simple search, but couldn’t immediately find them.
Any suggestions?

Trying to load a driver for the wrong architecture, perhaps?

Like an ARM64 driver on an x86 system?

Peter

Trying to load a driver for the wrong architecture, perhaps?

Well, I’ve selected x64 Debug build in VS2019, and the target VM is 64-bit aswell.

I did notice a very recent thread here: https://community.osr.com/discussion/291257/wdk-for-visual-studio-2019#latest
Maybe it is looking for a very new version of DLL’s or something? I will try to build it using VS2017.

depends.exe is ancient. It doesn’t understand apisets (“the long-named ones with L1-1-0 etc.”), so it just does something random and usually horrible with them. apisets are not just “dlls with a funny name”; they’re something completely novel. If you do continue to use depends.exe, you need to ignore whatever it says about apisets.

For problems loading drivers, try putting a breakpoint on nt!IopLoadDriver. You won’t have source debugging for the OS, but you can at least see what status code it returns (the value in the RAX register after you hit “gu”), which might give a hint.

For problems loading drivers, try putting a breakpoint on nt!IopLoadDriver.

Error code is 0xC0000033, STATUS_OBJECT_NAME_INVALID.

I found this thread, which suggests that it is due to some incorrect directory path:
https://community.osr.com/discussion/285540

I also noticed in the driver installation log setupapi.dev.log, the following snippet:

...
     dvi:                          Install Device: Configuring device (oem8.inf:root\mydevice,Install.NT). 21:14:25.579
     dvi:                          Install Device: Configuring device completed. 21:14:25.586
     dvi:                          Device Status: 0x01802001, Problem: 0x0 (0x00000000)
     dvi:                          Install Device: Starting device 'ROOT\SYSTEM\0002'. 21:14:25.592
     dvi:                          Install Device: Starting device completed. 21:15:25.683
!!!  dvi:                          Device not started: Device has problem: 0x27 (CM_PROB_DRIVER_FAILED_LOAD), problem status: 0xc0000033.
     dvi:                     {Configure Device - exit(0x00000000)} 21:15:25.696
     dvi:                     Device Status: 0x01802401, Problem: 0x27
     dvi:                     Device install status: 0x00000000
     dvi:                     Performing device install final cleanup...
...

Why does the system start a device node called ROOT\SYSTEM\0002, if I specified devcon install MyDevice1.inf ROOT\MYDEVICE on the cmdline? Perhaps that is why?

Hmmmmm.,. Is your DriverEntry definitely not getting called?

Peter

Place DbgBreakPoint in a DriverEntry to see if it will be triggered.

Regarding

Hmmmmm.,. Is your DriverEntry definitely not getting called?
and
Place DbgBreakPoint in a DriverEntry to see if it will be triggered.

How do I do that? I mean, if I do lm m M* in windbg, (my driver is called MyDriver1.sys), I can’t even find my driver in the list:

start             end                 module name
fffff800`30ac0000 fffff800`30ae2000   mcupdate_AuthenticAMD   (deferred)             
fffff800`30b40000 fffff800`30ba0000   msrpc      (deferred)             
fffff800`31200000 fffff800`31249000   mssecflt   (deferred)             
fffff800`31410000 fffff800`3141b000   msisadrv   (deferred)             
fffff800`31690000 fffff800`316af000   mountmgr   (deferred)             
fffff800`322d0000 fffff800`322f5000   mup        (deferred)             
fffff800`35a00000 fffff800`35a11000   Msfs       (deferred)             
fffff800`35dc0000 fffff800`35dd0000   mssmbios   (deferred)             
fffff800`365d0000 fffff800`3665f000   mrxsmb     (deferred)             
fffff800`36660000 fffff800`366a5000   mrxsmb20   (deferred)             
fffff800`36700000 fffff800`36719000   mslldp     (deferred)             
fffff800`368c0000 fffff800`368d3000   mouclass   (deferred)             
fffff800`369c0000 fffff800`369d6000   monitor    (deferred)             
fffff800`37f50000 fffff800`37f6a000   mpsdrv     (deferred)             
fffff800`38010000 fffff800`38024000   mmcss      (deferred)             
fffff800`38500000 fffff800`38510000   mouhid     (deferred)             

Unloaded modules:
fffff800`385c0000 fffff800`385d1000   mouhid.sys
fffff800`38540000 fffff800`38551000   mouhid.sys
fffff800`383e0000 fffff800`383f1000   mouhid.sys
fffff800`368a0000 fffff800`368b1000   mouhid.sys
Unable to enumerate user-mode unloaded modules, Win32 error 0n30

I don’t even see my module in the list. I was thinking that perhaps the driver installation process should load it, and after devcon returns I should be able to see it in the list, but I do not.

I can force it to load with the command .reload /f C:\Users\Maxim\dev\driver\MyDriver1\x64\Debug\mydriver1.sys, and then lm m M* reports

2: kd> lm m M*
Browse full module list
start             end                 module name
00000001`40000000 00000001`40007000   mydriver1 (private pdb symbols)  C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\sym\MyDriver1.pdb\107CB36BE6694AA5B18812360DB5D46A1\MyDriver1.pdb

...

but I really don’t know what this does, and feel like this is not what I’m supposed to do. The address is much more unusual than the other modules.

Nonetheless, I did try placing a breakpoint on it this way, but it was not triggered upon driver installation.

facepalm … Just found this little gem in my .INF:

[ServiceInstall]
ServiceType = 1
StartType = 1
ErrorControl = 1
ServiceBinary = %12%/MyDriver1.sys

Gotta love Unix vs Windows path separators. I changed the / to \, and now I get the following error:

     sto:                          {Configure Driver Package: exit(0x00000000)}
     dvi:                          Install Device: Configuring device (oem6.inf:root\mydevice,Install.NT). 20:28:27.264
     dvi:                          Install Device: Configuring device completed. 20:28:27.268
     dvi:                          Device Status: 0x01802001, Problem: 0x0 (0x00000000)
     dvi:                          Install Device: Starting device 'ROOT\SYSTEM\0001'. 20:28:27.270
     dvi:                          Install Device: Starting device completed. 20:28:27.292
!!!  dvi:                          Device not started: Device has problem: 0x25 (CM_PROB_FAILED_DRIVER_ENTRY), problem status: 0xc0000033.
     dvi:                     {Configure Device - exit(0x00000000)} 20:28:27.299

According to MSDN docs, this is due to an error returned from the corresponding driver’sDriverEntry routine, but I still can’t figure out how to add a breakpoint in my MyDriver1!DriverEntry function.

I can see my module in WinDbg under the Unloaded modules header:

0: kd> lm m M*
Browse full module list
start             end                 module name
fffff805`4de00000 fffff805`4de1a000   mpsdrv     (deferred)             
fffff805`4de40000 fffff805`4de54000   mmcss      (deferred)             
fffff805`4e260000 fffff805`4e273000   mouclass   (deferred)             
fffff805`4e2f0000 fffff805`4e31e000   mrxdav     (deferred)             
fffff805`51ac0000 fffff805`51ae2000   mcupdate_AuthenticAMD   (deferred)             
fffff805`51b40000 fffff805`51ba0000   msrpc      (deferred)             
fffff805`52200000 fffff805`52249000   mssecflt   (deferred)             
fffff805`52410000 fffff805`5241b000   msisadrv   (deferred)             
fffff805`52690000 fffff805`526af000   mountmgr   (deferred)             
fffff805`532d0000 fffff805`532f5000   mup        (deferred)             
fffff805`56b30000 fffff805`56b41000   Msfs       (deferred)             
fffff805`575c0000 fffff805`5764f000   mrxsmb     (deferred)             
fffff805`57650000 fffff805`57695000   mrxsmb20   (deferred)             
fffff805`576f0000 fffff805`57709000   mslldp     (deferred)             
fffff805`578f0000 fffff805`57906000   monitor    (deferred)             
fffff805`57b80000 fffff805`57b90000   mssmbios   (deferred)             

Unloaded modules:
fffff805`4e2e0000 fffff805`4e2e8000   MyDriver1.sys

Unfortunately, I cannot seem to be able to do anything with it. More googling…

Before your driver is loaded, break into the debugger and run the following

bu MyDriver!DriverEntry

and then load the driver (disable/enable in device manager should do the trick). Make sure your symbols are correct.

d

Or just code DbgBreakPoint() in your code.

Peter

bu MyDriver!DriverEntry
Unfortunately, for some reason I couldn’t get it to break using this method, but
Or just code DbgBreakPoint() in your code.
Worked.

my IoCreateDevice routine was returning 0xc0000033, aka STATUS_OBJECT_NAME_INVALID.
The DriverEntry routine is as follows:

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
//	UNREFERENCED_PARAMETER(DriverObject);
	UNREFERENCED_PARAMETER(RegistryPath);

	NTSTATUS status = STATUS_SUCCESS;
	UNICODE_STRING name, dos_name;
	PDEVICE_OBJECT obj;

	DbgBreakPoint();

	DbgPrint("Hello from DriverEntry\n");

	RtlInitUnicodeString(&name, L"\\\\Device\\myDevice1");
	RtlInitUnicodeString(&dos_name, L"\\\\DosDevices\\MyDevice1");

	status = IoCreateDevice(DriverObject, 0,
		&name, FILE_DEVICE_UNKNOWN, FILE_DEVICE_SECURE_OPEN, FALSE, &obj);

	init_mj_ptr(DriverObject);

	DriverObject->DriverUnload = DriverUnload;

	return status;
}

I replaced &name with NULL, and status became 0. The name and dos_name just happen to be variables which a guide that I’m trying to follow was using. They create a symbolic link between dos_name and name, but I just omitted that step, and from the MSDN docs I understand that giving a device a name is generally not advised?

However, after I let the machine run after the function left, the debugger reported a fatal system error with the below report.
Am I forgetting to inialize something in DriverEntry?

Another unrelated question: I am debugging on a real machine. When I boot in normal, non-debug average-joe-computer mode, it boots in 5 seconds (SSD). When I boot in debug mode with WinDbg attached, it takes about 4 to 5 minutes, which is ofcourse very annoying. Is there some way to speed this up? I am using an old 100Mbit switch. If I use 1Gbit, would it be faster?

1: kd> g
KDTARGET: Refreshing KD connection

*** Fatal System Error: 0x00000139
                       (0x0000000000000000,0x0000000000000000,0x0000000000000000,0x0000000000000000)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

For analysis of this file, run !analyze -v
nt!DbgBreakPointWithStatus:
fffff805`4d3c4580 cc              int     3
1: kd> !analyze -v
Connected to Windows 10 18362 x64 target at (Wed May 29 21:21:01.009 2019 (UTC + 1:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
..................................................
Loading User Symbols

Loading unloaded module list
..................Unable to enumerate user-mode unloaded modules, Win32 error 0n30
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure.  The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 0000000000000000, A stack-based buffer has been overrun.
Arg2: 0000000000000000, Address of the trap frame for the exception that caused the bugcheck
Arg3: 0000000000000000, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved

Debugging Details:
------------------


KEY_VALUES_STRING: 1


PROCESSES_ANALYSIS: 1

SERVICE_ANALYSIS: 1

STACKHASH_ANALYSIS: 1

TIMELINE_ANALYSIS: 1


DUMP_CLASS: 1

DUMP_QUALIFIER: 0

BUILD_VERSION_STRING:  18362.1.amd64fre.19h1_release.190318-1202

DUMP_TYPE:  0

BUGCHECK_P1: 0

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

TRAP_FRAME:  0000000000000000 -- (.trap 0x0)

EXCEPTION_RECORD:  0000000000000000 -- (.exr 0x0)
Cannot read Exception record @ 0000000000000000

CPU_COUNT: 8

CPU_MHZ: 10ee

CPU_VENDOR:  AuthenticAMD

CPU_FAMILY: 15

CPU_MODEL: 2

CPU_STEPPING: 0

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  0x139

PROCESS_NAME:  System

CURRENT_IRQL:  0

ANALYSIS_SESSION_HOST:  MSI

ANALYSIS_SESSION_TIME:  05-29-2019 21:21:02.0260

ANALYSIS_VERSION: 10.0.18362.1 amd64fre

LOCK_ADDRESS:  fffff8054d65d680 -- (!locks fffff8054d65d680)

Resource @ nt!PiEngineLock (0xfffff8054d65d680)    Exclusively owned
    Contention Count = 89
     Threads: ffffc78174f63040-01<*> 
1 total locks

PNP_TRIAGE_DATA: 
	Lock address  : 0xfffff8054d65d680
	Thread Count  : 1
	Thread address: 0xffffc78174f63040
	Thread wait   : 0x171ad

LAST_CONTROL_TRANSFER:  from fffff8054d4a6492 to fffff8054d3c4580

STACK_TEXT:  
ffff8089`8518df38 fffff805`4d4a6492 : 00000000`00000000 00000000`00000003 ffff8089`8518e0a0 fffff805`4d324f20 : nt!DbgBreakPointWithStatus
ffff8089`8518df40 fffff805`4d4a5b82 : 00000000`00000003 ffff8089`8518e0a0 fffff805`4d3d0ce0 00000000`00000139 : nt!KiBugCheckDebugBreak+0x12
ffff8089`8518dfa0 fffff805`4d3bc917 : ffffc781`00000200 ffff8089`8518e7f8 00000000`00000000 00000000`00000000 : nt!KeBugCheck2+0x952
ffff8089`8518e6a0 fffff805`4d3c516b : 00000000`00000139 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx+0x107
ffff8089`8518e6e0 fffff805`4d371973 : 00000000`00000001 ffff8089`8518e860 00000000`00000000 00000000`00000000 : nt!guard_icall_bugcheck+0x1b
ffff8089`8518e710 fffff805`4d92c0a2 : 00000000`00000000 00000000`00000003 ffffc781`752c8660 ffffb08b`22d91cb0 : nt!PpvUtilCallAddDevice+0x3b
ffff8089`8518e750 fffff805`4d8f5a6a : 00000000`00000003 00000000`00000000 00000000`6e657050 fffff805`00000000 : nt!PnpCallAddDevice+0x62
ffff8089`8518e7e0 fffff805`4d8f4d11 : ffffc781`752c8660 ffff8089`8518ea18 ffffc781`752c8660 00000000`00000000 : nt!PipCallDriverAddDevice+0x816
ffff8089`8518e9a0 fffff805`4da72612 : ffffc781`752c8600 ffffc781`73d94601 ffff8089`8518eab0 fffff805`00000000 : nt!PipProcessDevNodeTree+0x1b9
ffff8089`8518ea60 fffff805`4d45c94c : 00000001`00000003 ffffc781`752c8660 ffffd800`00000000 ffffc781`73d94650 : nt!PiRestartDevice+0xbe
ffff8089`8518eab0 fffff805`4d2ae835 : ffffc781`74f63040 ffffc781`6d47da30 fffff805`4d65bf20 ffffc781`7558e6f0 : nt!PnpDeviceActionWorker+0x10e1ec
ffff8089`8518eb70 fffff805`4d330925 : ffffc781`74f63040 00000000`00000080 ffffc781`6d477380 00000000`00000001 : nt!ExpWorkerThread+0x105
ffff8089`8518ec10 fffff805`4d3c3d5a : ffffd800`65b40180 ffffc781`74f63040 fffff805`4d3308d0 00000000`00000000 : nt!PspSystemThreadStartup+0x55
ffff8089`8518ec60 00000000`00000000 : ffff8089`8518f000 ffff8089`85189000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x2a


THREAD_SHA1_HASH_MOD_FUNC:  708dce6090c332f16964ae19ddc73ddf9b381880

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  9dcef127bd7514b2351edca7a38ec724f5be2879

THREAD_SHA1_HASH_MOD:  7f608ac2fbce9034a3386b1d51652e4911d30234

FOLLOWUP_IP: 
nt!guard_icall_bugcheck+1b
fffff805`4d3c516b 90              nop

FAULT_INSTR_CODE:  ccccc390

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  nt!guard_icall_bugcheck+1b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  0

IMAGE_VERSION:  10.0.18362.30

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  1b

FAILURE_BUCKET_ID:  0x139_0_LEGACY_GS_VIOLATION_nt!guard_icall_bugcheck

BUCKET_ID:  0x139_0_LEGACY_GS_VIOLATION_nt!guard_icall_bugcheck

PRIMARY_PROBLEM_CLASS:  0x139_0_LEGACY_GS_VIOLATION_nt!guard_icall_bugcheck

TARGET_TIME:  2019-05-29T20:20:31.000Z

OSBUILD:  18362

OSSERVICEPACK:  30

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK:  272

PRODUCT_TYPE:  1

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS

OS_LOCALE:  

USER_LCID:  0

OSBUILD_TIMESTAMP:  unknown_date

BUILDDATESTAMP_STR:  190318-1202

BUILDLAB_STR:  19h1_release

BUILDOSVER_STR:  10.0.18362.1.amd64fre.19h1_release.190318-1202

ANALYSIS_SESSION_ELAPSED_TIME:  472f

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0x139_0_legacy_gs_violation_nt!guard_icall_bugcheck

FAILURE_ID_HASH:  {9bee41a7-2ef9-07ca-7e59-7d5a0c6e2d05}

Followup:     MachineOwner
---------

I forgot to mention, on the target machine this is a bluescreen with stop code “KERNEL_SECURITY_CHECK_FAILURE”

Not reading any further, but:

    RtlInitUnicodeString(&name, L"\\\\Device\\myDevice1");
    RtlInitUnicodeString(&dos_name, L"\\\\DosDevices\\MyDevice1");

should be:

   RtlInitUnicodeString(&name, L"\\Device\\myDevice1");
   RtlInitUnicodeString(&dos_name, L"\\DosDevices\\MyDevice1");

I’m not going to ask why you’re writing a WDM driver.

Peter

I’m not going to ask why you’re writing a WDM driver.

Someone should.

@mblinov said:

I put “MyDriver1.sys” through depends.exe:

This doesn’t help solve the problem, but since you’re using depends.exe you might be interested in a more modern replacement for it, “Dependencies” at https://github.com/lucasg/Dependencies .

I’m not going to ask why you’re writing a WDM driver.

Probably, just because this is a non-PnP driver that creates its device objects right in DriverEntry()…

Anton Bassov

more modern replacement for it, “Dependencies”

Thank you for that, Ms. Cran. I hadn’t see that before, and I’m interested to check it out.

Peter