Windows native development: debuggee пытается загрузить werkernel.sys из system32

Теперь я изучаю API-интерфейс Windows, методы Nt*/Zw*. Я загрузил WDK, установил его и успешно скомпилировал приложение (x64, под Win 8.1 x64, VS2013). Единственное, что он делает, это позвонить в NtOpenFile().Windows native development: debuggee пытается загрузить werkernel.sys из system32

Для успешной компиляции/связать его, я должен был сделать следующие изменения проекта свойств (шаблон приложения для водителей):

Добавить включает в себя папку из WDK
Добавить папку Lib из WDK
Скажите компоновщик использовать ntoskrnl.lib

неожиданно, при запуске отладчика, я представил с сообщением об ошибке «программа не может начаться, потому что C: \ Windows \ System32 \ werkernel.sy s отсутствует на вашем компьютере. Попробуйте переустановить программу, чтобы устранить эту проблему « В werkernel.sys, очевидно, существует в system32 \ Drivers

EDIT:... Чтобы было ясно, упомянутая ошибка возникает также при запуске приложения, дважды щелкнув значок

Эта нагрузка происходит до того, как мой код, я ничего не могу найти где-нибудь в Интернете, ни в свойствах проекта на файл в вопросе так, чтобы подвести итог, у меня есть следующие вопросы до сих пор:.

Почему werkernel.sys загружается вообще для моего приложения?
Почему он загружается с системы32?

Я понимаю, что это возможно mklink werkernel.sys drivers\werkernel.sys, но похоже, что я делаю что-то ужасно неправильно.

источник

2015-03-18 Mike Makarov

Я использую Visual Studio. У меня есть другое приложение (в C#), которое использует NtQueryDirectoryInformationFile() - и там все работает нормально, поэтому я не ожидал никаких проблем с кодом на C++. На самом деле я хочу использовать NtOpenFile в этом приложении C#, но я застрял с ответом 0xc000000d от NtCreateFile, поэтому решил поиграть с ним с помощью WDK, чтобы увидеть, что я делаю неправильно на управляемой стороне. –

Какова опция/SUBSYSTEM, установленная на? (Свойства проекта, в Linker, System, Subsystem.) Кроме того, вы попытались использовать [ntdll.lib как задокументировано] (https://msdn.microsoft.com/en-us/library/bb432381%28v=vs.85% 29.aspx), а не ntoskrnl.lib? –

Да, это сработало. Спасибо! Как я писал ниже, меня смутила общая страница «прокси» для перенаправления NtCreateFile на ZwCreateFile. Кажется, что там, где Zw * говорит, что нужно подключить ntoskrnl.lib, на самом деле для NT * -функций нужно связать ntdll.lib. –

Ссылка на ntdll.lib, а не ntoskrnl.lib Работала для меня, когда у меня была аналогичная проблема.

источник

2015-03-20 21:18:41 user3553031

Спасибо, это помогло. Меня смутила общая перенаправление страницы NtOpenFile на [ZwOpenFile] (https://msdn.microsoft.com/en-us/library/windows/hardware/ff567011 (v = vs.85) .aspx), которая сообщает ссылке ntkrnl. lib –

NtOpenFile является то, что Microsoft не называет «внутренний API», она не должна быть использована для продукционной программного обеспечения, ни его следует использовать для экспериментов или использовать на всех, эти функции могут изменяться между каждым SP-релиз или основная версия Windows. (? WDK и UserMode Не вычислять ... если вы не на самом деле писать для UMDF)

Если вы хотите открыть файлы в UserMode вам рекомендуется использовать OpenFile:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365430(v=vs.85).aspx
или ваш водитель:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff567011(v=vs.85).aspx.

tl; dr: не используйте эти старые функции, они предназначены для использования.

заявление Microsoft о "внутреннем" API: https://msdn.microsoft.com/en-us/library/bb432200(v=vs.85).aspx

источник

2015-03-20 21:31:51 specializt

Это довольно старая страница, на которую вы ссылаетесь на BTW. Функции Nt/Zw прекрасно документированы. И если вы хотите узнать причину использования собственных функций в этом конкретном случае - рассмотрите 0,35 с для 2 вызовов NtQueryDirectoryInformationFile() против 12 секунд (да, двенадцать секунд!) Для FindFirst/FindNext/FindClose. Для NtOpenFile() я просто надеюсь, что это сделает приложение еще быстрее :) –

с использованием внутренних API-интерфейсов не ускоряет ваше приложение - это очень ошибочный вывод. Причина, по которой некоторые внутренние функции SEEM быстрее, - довольно неудобная истина: неправильное использование публичного API. Вы не сможете получить больше нескольких микросекунд для каждого Nt/Zw-вызова по сравнению со стандартными эквивалентами, ваш пример в значительной степени является доказательством того, что вы используете API неправильно. WINAPI очень сложно освоить, только очень немногие действительно знают, как правильно это сделать. О, и вы неправильно используете слово «native» - в WINAPI нет неместных функций. – specializt

Microsoft использует слово «native» как минимум двумя разными способами. Один из них - способ использования Майком - описать функции, которые являются частью ядра, а не частью подсистемы (например, Win32) или приложениями, которые запускаются непосредственно под ядром, а не внутри подсистемы. См., Например, [параметр/SUBSYSTEM] (https://msdn.microsoft.com/en-us/library/fcc1zstk.aspx). –

Windows native development: debuggee пытается загрузить werkernel.sys из system32

ответ

Смежные вопросы