Hello,

I tried to assemble a driver with Four-Fs includes from the great KmdKit,
but I always get this error on registering/running the .sys. I checked
the code several times, but everythings seems to be ok. The Entry point
is set correctly in the PE-Header even matching the code start.

Looking up the error here I found this thread and commented out all
Rtl-calls - but this didn't help, too.

Does anyone know what's going wrong and knows how to fix this?
Posted on 2003-03-03 08:49:28 by fxcb
I used to have the same problem with .exe's. It failed while starting with the same error, saying it couldn't find an entry point for "GetGlobalMemoryStatusVlm", an API that I didn't even use.

If you get errors for API's you're not using, you're probably using bad .lib files. Replace them with ones from Masm32 if possible.

If you get errors for API's that your code does use, it means the system can't find that API in the DLL.
Posted on 2003-03-03 09:07:41 by Qweerdy
Thx for the fast reply.
I checked the INCs and LIBs:

windows.inc and kernel32.inc (masmV8)
ntddk.inc,ntoskrnl.inc and hal.inc (from KMDKit 1.1)

kernel32.lib (masmV8)
ntoskrnl.lib and hal.lib (from KMDKit 1.1, checked vs. NTDDK 2k Free build -> ok)

So everything seems ok.
I have to mention everything assembles fine,
the error occurs on Run-Time on loading the driver.
Posted on 2003-03-03 09:32:41 by fxcb
Hi, fxcb!
You must not include windows.inc, kernel32.inc etc... into kmd sources.
Also don't link kernel32.lib etc...

Exclude these files and recompile your driver.
If error repeatedly occurs could you simplify your driver and send it to me (four-f@mail.ru) with compiled *.sys. And provide me with the info about your OS version.
Posted on 2003-03-03 09:47:31 by Four-F
Thx for your help, Four-F

That's it!
Of course, Kernel.inc/lib and windows.inc must not be included.
I replaced the one call to kernel32 and the error disappeared.

So here's my conclusion on what's been going wrong:

Calling a user-mode lib from kernel-mode -> BAD
Most kernel32-routines are wrappers to ntdll/ntoskrnl anyway,
so a ring0-call was addressed from ring0 by attempting to jump
to the ring3 wrapper pointing back to ring0 -> address conflict :rolleyes:
Posted on 2003-03-03 10:58:20 by fxcb