Кто-нибудь пробовал VirtualKD под 64-разрядной десяткой? Такое впечатление, что система не грузит интерфейсный модуль (kdbazis). Посмотрел родной сертификат в подписи — он был помечен как "not trusted", подписал своим — все равно не грузит. При загрузке запрещаю проверку сигнатур через F8. Обычные драйверы, подписанные моим сертификатом, работают нормально.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто-нибудь пробовал VirtualKD под 64-разрядной десяткой? Такое впечатление, что система не грузит интерфейсный модуль (kdbazis). Посмотрел родной сертификат в подписи — он был помечен как "not trusted", подписал своим — все равно не грузит. При загрузке запрещаю проверку сигнатур через F8. Обычные драйверы, подписанные моим сертификатом, работают нормально.
а вообще 10 выводит отладочные сообщения в com порт ? у меня на тех же самых настройках работает отладка в win8.1, win7 а на 10 почему то нет.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто-нибудь пробовал VirtualKD под 64-разрядной десяткой? Такое впечатление, что система не грузит интерфейсный модуль (kdbazis). Посмотрел родной сертификат в подписи — он был помечен как "not trusted", подписал своим — все равно не грузит. При загрузке запрещаю проверку сигнатур через F8. Обычные драйверы, подписанные моим сертификатом, работают нормально.
Ответ не совсем по теме.
Для виртуальных машин на основе Hyper-V есть встроенный в ОС модуль для быстрого kernel debug: kdvm.dll https://www.osronline.com/showthread.cfm?link=234398 (на Windows 8/7 использовал, в десятке не нашел, надо разбираться, что изменилось).
И отладка по сети (kdnet) доступна для всех ОС WIndows 8+
У VmWare есть некоторые проблемы при использовании kdnet(фактически не работает), в последних версиях обещали исправление.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто-нибудь пробовал VirtualKD под 64-разрядной десяткой? Такое впечатление, что система не грузит интерфейсный модуль (kdbazis). Посмотрел родной сертификат в подписи — он был помечен как "not trusted", подписал своим — все равно не грузит. При загрузке запрещаю проверку сигнатур через F8. Обычные драйверы, подписанные моим сертификатом, работают нормально.
С форума sysprogs:
1. VM: Copy kdbazis.dll and kdpatch.sys to C:\Windows\System32\drivers\
from virtualKD\target\x86 or x64.
2. VM: Run kdpatch.reg.
3. VM: Enable debug by serial port. (Use bcdedit or msconfig. Not vminstall.exe.)
4. Host: Start kernel debug by Windbg with serial port, and run vmmon.exe/vmmon64.exe.
After 5~10 seconds, Virtual Machine monitor starts transportation and debugging.
Здравствуйте, Ivan, Вы писали:
I>Для виртуальных машин на основе Hyper-V есть встроенный в ОС модуль для быстрого kernel debug: kdvm.dll https://www.osronline.com/showthread.cfm?link=234398 (на Windows 8/7 использовал, в десятке не нашел, надо разбираться, что изменилось).
В Windows 8.1 и 10, похоже, объединили модули kdnet.dll и kdhv.dll, теперь настройка отладки через Hyper-V еще проще. Внутри VM надо настроить обычный kdnet (с любым портом и hostip, имеет значение только ключ). И затем запустить скрипт, который включит отладку для vm на сервере Hyper-V (по приведенной выше ссылке скрипт, но он для первого поколения Hyper-V, для новых версий надо немного отредактировать).
Кстати, в WDK 10 в папке debuggers\ddk\samples есть интересный пример kdnet. В документации к нему описана архитектура extensibility модулей. Возможно, транспорт для vmware, vbox и др. можно будет реализовать как extensibility модуль kdnet для новых версий windows.
P.S. в документации обещают, что останется только kdnet, другие модули будут постепенно удалены
It is the long term plan to support all debugging of Windows through KDNET and KDNET extensibility modules. All other kernel transport DLLs (kdcom.dll, kd1394.dll, kdusb.dll, etc.) will eventually be deprecated and removed from Windows.
Здравствуйте, Ivan, Вы писали:
I>P.S. в документации обещают, что останется только kdnet, другие модули будут постепенно удалены I>
I>It is the long term plan to support all debugging of Windows through KDNET and KDNET extensibility modules. All other kernel transport DLLs (kdcom.dll, kd1394.dll, kdusb.dll, etc.) will eventually be deprecated and removed from Windows.
прощай bootdebug? врядли они com/1394 так лихо зарежут. usb — согласен.
Здравствуйте, mike_rs, Вы писали:
_>прощай bootdebug? врядли они com/1394 так лихо зарежут. usb — согласен.
Как я понял, не зарежут, сделают из них extensible modules для kdnet. Видимо, решили отделить транспорт от логики, вся логика в kdnet, а транспорт подключается через extensible modules.
It is designed so that the hardware support layer is built into a separate module from the network packet processing and kernel interface layer. This hardware driver support layer is called a KDNET extensibility module.
...
There are two types of interfaces that KDNET uses to communicate with KDNET extensibility modules. One is a packet based interface that is used for NICs, USB, and wireless hardware, and the other is a byte based interface that is used to support KDNET over serial hardware.
Здравствуйте, mike_rs, Вы писали:
_>2. VM: Run kdpatch.reg.
Что-то это метод, хоть и работает, но связь между отладчиком и системой устанавливается один раз из пяти.
_>4. Host: Start kernel debug by Windbg with serial port, and run vmmon.exe/vmmon64.exe.
Тут они явно врут — каким образом может быть установлена связь, если отладчик будет слушать пайп, созданный VMware для COM-порта? Запускать нужно именно с пайпом, созданным VMMon, и не до запуска VMMon, а после.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, mike_rs, Вы писали:
_>>2. VM: Run kdpatch.reg.
ЕМ>Что-то это метод, хоть и работает, но связь между отладчиком и системой устанавливается один раз из пяти.
_>>4. Host: Start kernel debug by Windbg with serial port, and run vmmon.exe/vmmon64.exe.
ЕМ>Тут они явно врут — каким образом может быть установлена связь, если отладчик будет слушать пайп, созданный VMware для COM-порта? Запускать нужно именно с пайпом, созданным VMMon, и не до запуска VMMon, а после.
все правильно написано. Объяснение магии: сначала ты коннектишься отладчиком через обычный com порт, это приводит к отключению проверки подписей и нормальной загрузке транспорта virtualkd (kdbazis.dll), после чего второй дебаггер уже нормально коннектится через виртуалкдшный пайп, а первый (который по кому) можно смело отключить.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Ivan, Вы писали:
ЕМ>От какой логики? В KDxxx всегда и был только транспорт.
Логики реализации протокола KD. KdSendPacket и KdReceivePacket не только отправляют и получают данные, но еще и анализируют и реагируют на выставленные флаги и т.д. В новом kdnet добавилась еще логика шифрования и проверки подписи пакетов, которая также не зависит от физического транспорта.
Насколько я понял, в новом API extensible modules, Send и Receive просто отправляют и получают буферы с данными, ничего не зная о протоколе KD, его флажках, шифровании т т.д.
KdSendPacket normally guarantees that the data has been received and acknowledged by the remote end. However, if the request being sent is a debug print notification, a symbol load notification, or a .kdfiles request, KdSendPacket contains a special exemption that allows the transmission to time out and silently fail after several attempts. This is because these requests can happen normally and don’t always warrant a debugger break in. (For example, a debug print doesn’t halt the system until you attach the kernel debugger because of this exemption.)
KdReceivePacket will keep trying to receive the packet until it either times out (i.e. there is no activity on the KD link for a specific amount of read attempts), successfully receives a good packet and acknowledges it, or receives a resend or resynchronize request (the latter two being specific to the KD protocol module and its internal framing protocol used “on the wire”).
KdReceivePacket supports a special type of request by the caller to check if there is a debugger present and requesting a break in at the instant in time when it is called (returning immediately with the result). This mode is used by the kernel on the system timer tick to periodically check if the kernel debugger is requesting to break in.
Здравствуйте, mike_rs, Вы писали:
_>сначала ты коннектишься отладчиком через обычный com порт, это приводит к отключению проверки подписей и нормальной загрузке транспорта virtualkd (kdbazis.dll), после чего второй дебаггер уже нормально коннектится через виртуалкдшный пайп, а первый (который по кому) можно смело отключить.
Извращение. А почему транспорт kdbazis под десяткой не грузится сам по себе, даже с отключенной проверке подписей?
Здравствуйте, Ivan, Вы писали:
I>Насколько я понял, в новом API extensible modules, Send и Receive просто отправляют и получают буферы с данными, ничего не зная о протоколе KD, его флажках, шифровании т т.д.
Ну да, если там еще и подписи/шифрование прикрутили — тады, конечно.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, mike_rs, Вы писали:
_>>сначала ты коннектишься отладчиком через обычный com порт, это приводит к отключению проверки подписей и нормальной загрузке транспорта virtualkd (kdbazis.dll), после чего второй дебаггер уже нормально коннектится через виртуалкдшный пайп, а первый (который по кому) можно смело отключить.
ЕМ>Извращение. А почему транспорт kdbazis под десяткой не грузится сам по себе, даже с отключенной проверке подписей?
а подпись все равно проверяется для early launch драйверов, а она у kdbazis кривая, для 10ки не проходит. Если его кошерно подписать, то все работает и без бубна.
Здравствуйте, mike_rs, Вы писали:
_>а подпись все равно проверяется для early launch драйверов, а она у kdbazis кривая, для 10ки не проходит. Если его кошерно подписать, то все работает и без бубна.
Я его подписал своей, с которой нормально работает обычный 64-разрядный драйвер — все равно система его не грузит.
И в восьмерке, кстати, та же самая фигня — даже после подписывания своей подписью, без F8 kdbazis.dll не грузится.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я его подписал своей, с которой нормально работает обычный 64-разрядный драйвер — все равно система его не грузит. ЕМ>И в восьмерке, кстати, та же самая фигня — даже после подписывания своей подписью, без F8 kdbazis.dll не грузится.
можно попробовать сделать тестовую подпись и включить testsigning
Здравствуйте, mike_rs, Вы писали:
_>сначала ты коннектишься отладчиком через обычный com порт, это приводит к отключению проверки подписей и нормальной загрузке транспорта virtualkd (kdbazis.dll), после чего второй дебаггер уже нормально коннектится через виртуалкдшный пайп, а первый (который по кому) можно смело отключить.
Offtop.
Живем в 21-ом веке, а удобного и быстрого транспорта для кернел-отладки до сих пор нет.
COM\pipe медленный. VirtualKD спасает, но приходится иногда делать "магию" вроде той, что описана выше.
На Windows 10, как видим, еще какие-то проблемы. У других "booster-ов" такие же заморочки.
IEEE/1394 не эмулируется VMWare\Hyper-V\VBox (да и на реальных машинах чаще всего отсутствует).
USB 2.0 глючный. USB 3.0 и Network поддерживаются только с Windows 8 (Network еще требует
совместимую сетевую карту и там другие ограничения).
Здравствуйте, okman, Вы писали:
O>Живем в 21-ом веке, а удобного и быстрого транспорта для кернел-отладки до сих пор нет.
Как это нет? А netconsole? Спокойно гигабитные потоки сообщений передаются.
Здравствуйте, okman, Вы писали:
O>IEEE/1394 не эмулируется VMWare\Hyper-V\VBox (да и на реальных машинах чаще всего отсутствует).
Для Hyper-V есть dll: kdhv1394.dll, а в WMI находил атрибут DebugChannelId, возможно, работает аналогично kdhv, но заводить не пробовал.
O>Network еще требует совместимую сетевую карту и там другие ограничения).
С некоторыми манипуляциями kdnet можно завести на Windows 7.
Кстати, для информации по kdnet. Он (похоже) не поддерживает фрагментацию UDP, на новых процессорах Intel контекст может превышать размер mtu, и отладка отваливается. Как вариант, можно отключать в гостевой ОС расширенный контекст AVX: bcdedit /set xsavedisable 1
O>Как-то дремуче это все...
Согласен. Но если использовать Hyper-V с synthetic debug device, то для ОС с Vista и до 10-ки отладку с теми или иными ограничениями можно организовать без танцев с бубном типа нажатия F8 во время загрузки и др.
Здравствуйте, Ivan, Вы писали:
I>Кстати, для информации по kdnet. Он (похоже) не поддерживает фрагментацию UDP, на новых процессорах Intel контекст может превышать размер mtu, и отладка отваливается.
В виртуалках VMware он еще и дико тормозной. Если поток выводит отладочные сообщения хотя бы по десятку в секунду, то вся VM начинает тормозить так, что аж окна мышкой только рывками перемещаются, и вводимые символы появляются с задержкой в несколько секунд.
Кстати, в последних билдах десятки (по-моему, начиная с 1803) опять что-то поломали, и дефолтная установка VirtualKD снова перестала работать. Я из-за этого какое-то время прожил с kdnet, но сегодня из-за тормозов стало совсем невмоготу, и взялся за эксперименты. Выяснилось, что параметр dbgtransport=kdcom.dll, который установщик VirtualKD добавляет в BCD (kdcom.dll — это переименованный kdbazis.dll), больше не грузит модуль. Помогло удаление dbgtransport и внесение debugtype=serial. Счастья — полные штаны.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто-нибудь пробовал VirtualKD под 64-разрядной десяткой? Такое впечатление, что система не грузит интерфейсный модуль (kdbazis). Посмотрел родной сертификат в подписи — он был помечен как "not trusted", подписал своим — все равно не грузит. При загрузке запрещаю проверку сигнатур через F8. Обычные драйверы, подписанные моим сертификатом, работают нормально.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, mike_rs, Вы писали:
_>>версия 3.0 работает без проблем на всех десятках
ЕМ>Если бы она работала во всех — ни я, ни другие не извращались бы.
а она и работает, ни я, ни мои коллеги не извращаются совершенно, а просто устанавливают и работают
Здравствуйте, mike_rs, Вы писали:
_>а она и работает, ни я, ни мои коллеги не извращаются совершенно, а просто устанавливают и работают
А я еще не настолько выжил из ума, чтобы несколько раз повторившаяся ситуация мне приблазнилась. Возможно, глюк зависит от каких-то условий, которые есть у меня, но нет у вас с коллегами.
Здравствуйте, mike_rs, Вы писали:
_>>>версия 3.0 работает без проблем на всех десятках
ЕМ>>Если бы она работала во всех — ни я, ни другие не извращались бы.
_>а она и работает, ни я, ни мои коллеги не извращаются совершенно, а просто устанавливают и работают
Вот я только что установил релиз 2004, полностью с нуля. Установил VirtualKD его родным инсталлятором, с параметрами по умолчанию (создавать новую запись BCD, подменять kdcom.dll). Перегружаю VM, VMMon ее определяет и инициализирует, вхожу в Boot Menu, выбираю Disable Driver Signature Enforcement. Грузится винда, отладчик не запускается.
Сумеете объяснить, что я в который раз сделал не так?
ЕМ>Вот я только что установил релиз 2004, полностью с нуля. Установил VirtualKD его родным инсталлятором, с параметрами по умолчанию (создавать новую запись BCD, подменять kdcom.dll).
теперь запускаешь msconfig.exe и на вкладке debug проверяешь, что debug port указан как com1, меняешь если не так и все.
ps: VirtualKD должен быть версии 3.0
ЕМ>Перегружаю VM, VMMon ее определяет и инициализирует, вхожу в Boot Menu, выбираю Disable Driver Signature Enforcement. Грузится винда, отладчик не запускается. ЕМ>Сумеете объяснить, что я в который раз сделал не так?
Здравствуйте, mike_rs, Вы писали:
_>теперь запускаешь msconfig.exe и на вкладке debug проверяешь, что debug port указан как com1, меняешь если не так и все.
Эк Вы ловко переобулись. В исходном варианте утверждалось "просто устанавливают и работают". Чем Ваше шаманство с msconfig лучше моего с dbgtransport?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, mike_rs, Вы писали:
_>>теперь запускаешь msconfig.exe и на вкладке debug проверяешь, что debug port указан как com1, меняешь если не так и все.
ЕМ>Эк Вы ловко переобулись. В исходном варианте утверждалось "просто устанавливают и работают". Чем Ваше шаманство с msconfig лучше моего с dbgtransport?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, mike_rs, Вы писали:
_>>скажи спасибо лучше
ЕМ>Разработчикам VirtualKD — большое спасибо. А Вам за что?
_>>вместо извиваний.
ЕМ>Кто бы говорил...
Выяснилось, что параметр dbgtransport=kdcom.dll, который установщик VirtualKD добавляет в BCD (kdcom.dll — это переименованный kdbazis.dll), больше не грузит модуль. Помогло удаление dbgtransport и внесение debugtype=serial. Счастья — полные штаны. 
