гляньте https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlcapturecontext они идут в паре
скорее генерить бсоды на реальной свой машине никому не хочется, а ставить бесятку на вм - идея так себе. лично у меня вообще Win7, а в ней с этим семплом всё гуд.
Marylin, а я что бы решать проблему MessageBox без импорта поставил на виртуальную машину Win7, после Win10 семерка уже не айс, вроде бы почти всё как на десятке, но что-то все равно не так, к хорошему быстро привыкаешь
и что же такого хорошего в БЕСятке (кроме рюшечек да ряшечек) = marketing MS bulls.t https://www.minitool.com/backup-tips/windows-10-sucks.html
ну у меня есть и Win10 на буке, только мне она наоборот не нравится.. как говорит alex_dz, - кроме бесполезного фейса нет в ней ничего особенного (если не считать поддержки майков). кстати хотя от Win7 вроде как MS открестилась, мне почему-то обновы до сих пор приходят - последний раз вот было 12-го числа.
Ahimov, пока проверить не могу, т.к. ноута при себе нет (возможно на выходные детки принесут). но зачем мне явно генерить бсод на реальной машине, я так и не пойму. была-бы виртуалка - ещё ладно. --- Сообщение объединено, 15 мар 2025 --- а на семёрке я кодес проверял в WinDbg командой go, и вроде отработал без проблем. --- Сообщение объединено, 15 мар 2025 --- Код (Text): 0:000:x86> g Breakpoint 0 hit image00000000_00400000+0x1000: 00401000 9c pushfd 0:000:x86> g test 0e28:0ea8 @ 36926669 - LdrShutdownProcess - INFO: Process 0xe28 (F:\test.exe) exiting ntdll!ZwTerminateProcess+0xa: 00000000`772b8d8a c3 ret
Marylin, > зачем мне явно генерить бсод Узнать что проблема не только в моём билде. Почему составляет проблему раз ребутнуться ? При отладке темы с кл я вчера пол сотни раз ребутался, причём с руганью из за невнимательности(тк нужно пропускать popf) Варя после бсодов отвалилась --- Сообщение объединено, 15 мар 2025 --- > на семёрке я кодес проверял в WinDbg командой go Оно крэшит при пошаговой отладке, вд не падает, наверно использует точки останова.
Похоже, что проблема всё-таки только у тебя. Специально поставил 19041 и спокойно прошагал по твоему приложению через все pushf'ы и popf'ы.
HoShiMin Спасибо!! Это может означать что ядро изменено патчем, какое то обновление и это можно откатить назад ? Как это выяснить ? А если сравнить два ядра как это обычно делалось при поиске уязвимостей ?
Когда производится системный патч, то что бы разобрать его с целью найти крит уязвимость брался турбодифф и тп, так находился измененный код. Но это делалось на одной системе. Этим я очень давно не занимался, это нужно искать матчасть или мб кто знает как это сейчас делается. Плагины к иде ?
Ну смотри, я бы не был так категоричен. В этой истории интересно, что у тебя воспроизвелось и на икспишке в виртуалке. Рассмотри несколько вариантов: 1. Возможно, у тебя стоит какой-нибудь продвинутый антивирус, типа касперского с гипервизором, который криво что-то обрабатывает. Причём, это может сказываться и на виртуалках, которые ты запускаешь на этой машине, поскольку внешний гипервизор ловит и обрабатывает события первым. Если стоят какие-то антивирусы или песочницы - отключай. 2. Если включен Hyper-V или любой из его компонентов - выключи: это может быть изоляция ядра, HVCI/DeviceGuard, Credential Guard, WSL, Windows Sandbox, платформа низкоуровневой оболочки (в «программах и компонентах»). Если хоть что-то из этого включено - у тебя автоматически включается Hyper-V, и вся твоя хостовая система запускается под виртуализацией. Баг в гипервизоре вполне может стать причиной, что у тебя падает и на хосте, и в виртуалках. 3. Это вообще может быть баг в самом процессоре или в его микрокоде, такое хоть и редко, но случается: можешь попробовать обновить биос. 4. Если всё-таки баг в ядре, не откатывай обновления, а наоборот, обновляйся вверх: 19041 - очень старая сборка пятилетней давности. Для начала просто поставь все обновления из центра обновлений, включая необязательные (они там в отдельном меню, и там, в основном, обновления драйверов). В итоге система прыгнет на билд 19045. Диффать смысла нет: с чем сравнивать? С предыдущим билдом бесполезно: сделаешь дифф, увидишь миллиард изменений, закроешь дифф. А сторонние патчи там очень маловероятны: PatchGuard бы постоянно валил ядро. Ну и самое логичное решение: ПРИШЛО ВРЕМЯ ПЕРЕУСТАНАВЛИВАТЬ ШИНДОВС!
HoShiMin Разумеется никаких аверов не стоит. Хард ошибка врядле возможна - падение было бы сразу на инструкции и что не понятно оно стабильно в части ядра, занимающимся планированием. Килять ось не вариант, хочется разобраться, понять суть, баг не обычный. Проще другой ноут взять конечно.
Я просто зацепился за то, что у тебя падает и на виртуалке. Это необычный признак: будь баг в планировщике или ядерных сервисах для отладки - на виртуалке бы не падало. Ну… скорей всего не падало бы, потому что в виртуалке тоже может быть баг, вообще никак не связанный с твоим, но приводящий к падению на тех же инструкциях. Не знаю, поставь ещё какую-нибудь вм, чтобы понять, зависит ли это от системы, или на всех виртуалках падает одинаково. Или вообще сменить виртуалку (с виртуалбокса на вмварю, или их обе на Hyper-V, и проверить там). Внезапно, можно даже попробовать линукс. --- Сообщение объединено, 16 мар 2025 --- Кстати, ещё момент: на твоих фотках бсод показывает четыре аргумента в левом верхнем углу экрана. А как ты это сделал? На экране бсода же аргументов нет. Это ты где-то настраивал или оно само так показывает? --- Сообщение объединено, 16 мар 2025 --- Upd: вроде это: https://superuser.com/questions/103...w-more-details-like-older-versions-of-windows Прикольно, не знал.
> А как ты это сделал? Ничего не делал, в разных юзер отладчиках нажимал f8 на popf. > Или вообще сменить виртуалку Но я ведь это и сделал, попробовал варю и вб. Первая крэшила без бсода вроде я уже запутался, при переходе на фулскрин, я даже кнопку скотчем заклеил что бы рефлекторно при отладке не нажимать ctrl+g Попробую переустановить и заново все проверить. Но как бы там небыло, мне не дает покоя крэшдамп, его же можно разобрать в принципе. Можно попробовать поискать cpu-errata, может что то портится и далее приводит к падению шедулера.
Можно проверить имя\версию ядра именно в памяти, а не на диске. Например у меня на прежней Win7 ядро было пропатченное, так в озу оно лежало под ником xNtKrnl.exe, хотя на винте файл с таким именем я вообще не мог найти ни поиском мастдая по Win+F, ни в тотале по Alt+F7. А главное функция NtQuerySystemInformation() с классом module(11) тоже возвращала штатное ядро Ntoskrnl.exe. Я нашёл реальное ядро случайно в WinDbg командой lmv m nt, где параметр(v) от verbose (расширенная инфа), а параметр(m) маска\фильтр для поиска. После переустановил ос, и теперь вроде видит валидное, хотя функа qsi по-прежнему говорит, что это Ntoskrnl.exe, в то время как реально воркает Ntkrnlp.exe.
Marylin Оно так и есть. На диске ntoskrnl, хотя должно быть ntkrnlpa или типо того и в дампах выше имя тоже ntkrnlmp.
