Возможно, это не вся проблема, но одна вещь, которая выпадает из приведенного кода, это вызов CreateFile("\\.\\NdisProt",...). Правильный путь к объекту в пространстве имен ядра начинается с двух обратных косых черт, каждый из которых должен быть удвоен в строке C. У меня были проблемы с языком разметки, используемым в SO, который был перепутан с обратными слешами в прошлом, поэтому я позволил себе отредактировать ваш вопрос, чтобы убедиться, что вижу имя, которое вы намеревались представить, и исправить разметку, чтобы сохранить это намерение.
Итак, имя, используемое для создания дескриптора объекта устройства, должно выглядеть как
CreateFile("\\\\.\\NdisProt",...)
для адресации объекта устройства с именем
\\.\NdisProt
Я понятия не имею, есть ли какие-либо другие проблемы, или даже если это правильное имя, экспортированное этим драйвером.
Образцы DDK, как правило, пишутся так, чтобы не зависеть от таких вещей, как MFC, ATL, WTL и тому подобное. Это приводит к некоему стилю стиля в коде, но имеет то преимущество, что примеры могут быть построены с помощью цепочки инструментов, которая изначально поставлялась с самим DDK, и относительно независимы от выбора используемого набора инструментов.
Обратите внимание, что если вы попытаетесь действительно отладить драйвер, вам может потребоваться отследить вызов из кода режима пользователя через ядро и в соответствующие биты драйвера. Сделать это с помощью отладчика ядра проще, если код пользовательского режима максимально прост. Это также может объяснить стиль, используемый в примере кода.
Редактировать: Если существует также плавающая проблема Unicode и ANSI, то вы должны проверить свой код на наличие мест, где узкие строки передаются в API, которые ожидают широкие строки и исправляют их.
Одним из простых решений было бы переключиться на компиляцию ANSI для всех API Windows. Конечно, теперь у вас есть проблемы с именами файлов, которые содержат национальные символы, которых нет в вашей текущей кодовой странице, поскольку нет способа гарантировать, что имя файла Unicode может быть правильно переведено в ANSI и из него.
Единственное исправление, которое может быть «достаточно хорошим», - сделать строковые константы широкими, написав их L"...". Однако теперь ваш код гарантированно не будет переносимым обратно к компиляции ANSI, поэтому обязательно используйте утверждение времени компиляции, чтобы убедиться, что определено UNICODE, и тогда вы получите хорошее сообщение об ошибке.
Похоже, что на вечеринке в Microsoft никогда не используют char или wchar_t, а вместо этого используют TCHAR. Заголовок <tchar.h> содержит макросы сопоставления, которые позволяют объявлять и использовать строки в API Windows и в библиотеках времени выполнения C, выбирая широкий или узкий API во время компиляции. Возможно, это правильное действие в приложении Windows, поскольку оно уже не очень переносимо на другие платформы.
Однако, получение магии магии для правильного перевода TCHAR s в известное представление - это боль.
Независимо от того, какую технику вы выберете, я не вижу выхода из тщательного и полного анализа кода для предположений об обработке строк и представлении символов.