Mike Makarov
Mike Makarov

Reputation: 1356

Windows native development: debuggee tries to load werkernel.sys from system32

I'm investigating the Windows Native API now, Nt*/Zw* methods. I downloaded the WDK, installed it and successfully compiled an application (x64, under Win 8.1 x64, VS2013). The only thing it does is a call to NtOpenFile().

To successfully compile/link it, I had to make the following changes to project properties (template Application For Drivers):

Unexpectedly, upon running a debugger, I'm presented with error message "The program can't start because C:\Windows\SYSTEM32\werkernel.sys is missing from your computer. Try reinstalling the program to fix this problem." The werkernel.sys obviously exists in system32\drivers.

EDIT: To be clear, the mentioned error also occurs when launching the app by doubleclicking the icon.

This load happens before any of my code, I can't find anything anywhere in internet nor in project properties on the file in question. So, to summarize, I have the following questions so far:

  1. Why werkernel.sys is being loaded at all for my application?
  2. Why is it being loaded from System32?

I understand that it is possible to mklink werkernel.sys drivers\werkernel.sys, but it feels like I'm doing somethig terribly wrong.

Upvotes: 2

Views: 551

Answers (2)

specializt
specializt

Reputation: 1911

NtOpenFile is what Microsoft calls "internal API", it should not be used for productional software, neither should it be used for experimentation or be used at all, these functions are subject to change between each SP-release or major windows-version.

If you want to open files in user-mode (WDK and usermode? Does not compute ... unless you're actually writing for UMDF) you are advised to use OpenFile :
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365430(v=vs.85).aspx
or in your driver :
https://msdn.microsoft.com/en-us/library/windows/hardware/ff567011(v=vs.85).aspx.

tl;dr : dont use these old functions, they arent meant to be used.

Microsoft statement on "internal" API : https://msdn.microsoft.com/en-us/library/bb432200(v=vs.85).aspx

Upvotes: 1

user3553031
user3553031

Reputation: 6224

Linking ntdll.lib rather than ntoskrnl.lib worked for me when I had a similar problem.

Upvotes: 2

Related Questions