alex_dz, А на 10-ке ? Падает шедулер(планировщик) при переключении контекста. Я думал такое невозможно. Конечно я сразу крэшдамп посмотрел.
alex_dz, А это что ?? Код (Text): BUGCHECK_CODE: 3b BUGCHECK_P1: c0000005 BUGCHECK_P2: fffff8026401be7b BUGCHECK_P3: ffffde8021060d30 BUGCHECK_P4: 0 FILE_IN_CAB: MEMORY.DMP FAULTING_THREAD: ffff8001e6dee080 CONTEXT: ffffde8021060d30 -- (.cxr 0xffffde8021060d30) rax=00000000000001d2 rbx=0000000000000000 rcx=ffffde80210618f0 rdx=0000000000000000 rsi=0000000000000002 rdi=ffff8001e6dee180 rip=fffff8026401be7b rsp=ffffde8021061730 rbp=0000000000000000 r8=0000000000000001 r9=0000000000000002 r10=0000000000000000 r11=fffff80263e00000 r12=0000000000000001 r13=0000000000000000 r14=ffff8001e6dee1c0 r15=0000000000000000 iopl=0 nv up ei pl zr na po nc cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00010246 nt!KiSwapThread+0x6db: fffff802`6401be7b c6401104 mov byte ptr [rax+11h],4 ds:002b:00000000`000001e3=?? Resetting default scope PROCESS_NAME: x32dbg.exe STACK_TEXT: ffffde80`21061730 fffff802`6401b1cf : ffff8001`e6dee080 ffff8001`000008b0 ffffde80`210618f0 00000000`00000000 : nt!KiSwapThread+0x6db ffffde80`210617e0 fffff802`6401aa73 : 00000000`00000002 fffff802`00000000 8001e476`b0500001 ffff8001`e6dee1c0 : nt!KiCommitThreadWait+0x14f ffffde80`21061880 fffff802`64689d21 : ffff8001`e7004f00 00000000`00000000 ffffde80`21061b01 ffff8001`deca7d01 : nt!KeWaitForSingleObject+0x233 ffffde80`21061970 fffff802`64210ef5 : ffff8001`e6dee080 00007ffc`aed6b3f0 00000000`00000000 ffff8001`e7004f00 : nt!NtWaitForDebugEvent+0x261 ffffde80`21061b00 00007ffc`aee90a34 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25 00000000`05e5e378 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffc`aee90a34 --- Сообщение объединено, 7 мар 2025 в 19:05 --- У меня нет вари, так что я не особо хочу эксперименты проводить, нужно ребутаться каждый раз. Вот сейчас на телефон записал видос. Сорян за тремор конечно, это от нейролептиков
Инфа из дампа, мб кто разобраться захочет. Виндебаг не падает. --- Сообщение объединено, 8 мар 2025 в 12:05 --- Если посмотреть место падания, получается вот что: Код (Text): fffff801`2d81be5e 488d8e00010000 lea rcx, [rsi+100h] fffff801`2d81be65 b201 mov dl, 1 fffff801`2d81be67 e834150000 call ntkrnlmp!KiCancelTimer (fffff8012d81d3a0) fffff801`2d81be6c 84c0 test al, al fffff801`2d81be6e 0f855afeffff jne ntkrnlmp!KiSwapThread+0x52e (fffff8012d81bcce) fffff801`2d81be74 488d86d0010000 lea rax, [rsi+1D0h] fffff801`2d81be7b c6401104 mov byte ptr [rax+11h], 4 rax+11h = 1E3 fffff801`2d81be74 488d86d0010000 lea rax, [rsi+1D0h] rax = rsi+1D0 rsi = 2 Но прежде наверно вызывается KiCancelTimer(rsi+100h) и если бы rsi был невалид, то падала бы KiCancelTimer() --- Сообщение объединено, 8 мар 2025 в 14:21 --- Не понятно.
Глянул, у меня на Win11 не воспроизвелось (десятки под рукой нет) - запускал и просто так, и под отладчиком пошагово (как у тебя на видео). Пробовал и на OllyDbg, и под x64dbg - не падает. Сравни, чему равен rsi до KiCancelTimer и после - возможно, он испортился после вызова (адрес-то и правда невалидный).
HoShiMin, Не могу узнать значение, так как локально вд не работает. Есть полный крэшдамп, что там можно посмотреть ? Адрес крэша один и тот же, не зависимо от отладчика, баг не плавающий". Вот сейчас олей попробую, придётся подождать пока ребутнусь. --- Сообщение объединено, 8 мар 2025 в 16:28 --- Упало, но уже другая ошибка почему то: Код (Text): BUGCHECK_CODE: f7 BUGCHECK_P1: ffffe08b5fd2bcf0 BUGCHECK_P2: 61356ec0f8fd BUGCHECK_P3: ffff9eca913f0702 BUGCHECK_P4: 0 FILE_IN_CAB: MEMORY.DMP FAULTING_THREAD: ffffc40697ae8080 SECURITY_COOKIE: Expected 000061356ec0f8fd found ffffe08b5fd2bcf0 BLACKBOXNTFS: 1 (!blackboxntfs) BLACKBOXPNP: 1 (!blackboxpnp) BLACKBOXWINLOGON: 1 PROCESS_NAME: test.exe TRAP_FRAME: ffff800000000000 -- (.trap 0xffff800000000000) Unable to read trap frame at ffff8000`00000000 Resetting default scope STACK_TEXT: ffffe08b`5fd2aa98 fffff801`786b63c5 : 00000000`000000f7 ffffe08b`5fd2bcf0 00006135`6ec0f8fd ffff9eca`913f0702 : nt!KeBugCheckEx ffffe08b`5fd2aaa0 fffff801`785d5a8e : ffffe08b`5fd2b0b0 fffff801`784ca5df fffff801`7831bf38 00000af8`00000000 : nt!_report_gsfailure+0x25 ffffe08b`5fd2aae0 fffff801`785d5a23 : ffffe08b`5fd2abb0 00000000`00000000 ffffe08b`5fd2b0e8 ffffe08b`5fd2b0c0 : nt!_GSHandlerCheckCommon+0x5a ffffe08b`5fd2ab10 fffff801`78607d2f : fffff801`785d5a10 00000000`00000000 00000000`00000000 00000000`00000000 : nt!_GSHandlerCheck+0x13 ffffe08b`5fd2ab40 fffff801`784ca3c7 : ffffe08b`5fd2b0b0 00000000`00000000 ffffe08b`5fd2bcf0 fffff801`78a88daa : nt!RtlpExecuteHandlerForException+0xf ffffe08b`5fd2ab70 fffff801`784c94e6 : ffffe08b`5fd2ba88 ffffe08b`5fd2b7c0 ffffe08b`5fd2ba88 00000000`00000000 : nt!RtlDispatchException+0x297 ffffe08b`5fd2b290 fffff801`7861186c : 00000000`00001000 ffffe08b`5fd2bb30 ffff8000`00000000 00000000`00000000 : nt!KiDispatchException+0x186 ffffe08b`5fd2b950 fffff801`7860d2bd : ffffc406`97ae8080 00000000`00000002 00000000`00000000 fffff801`78e47960 : nt!KiExceptionDispatch+0x12c ffffe08b`5fd2bb30 fffff801`7841dfba : ffffc406`97ae8080 fffff801`78a88da5 00000000`00000010 00000000`00000246 : nt!KiPageFault+0x43d ffffe08b`5fd2bcc0 fffff801`78a88daa : fffff801`78e47960 00000000`00000000 00000000`00000000 ffffe08b`5fd2bfa0 : nt!ExReleaseFastMutex+0xa ffffe08b`5fd2bcf0 00000000`00000001 : 00000000`0009fda0 ffffe08b`5fd2ca58 ffffc406`9b7dc080 ffffc406`9b7dc080 : nt!DbgkpQueueMessage+0x222 ffffe08b`5fd2bef0 00000000`0009fda0 : ffffe08b`5fd2ca58 ffffc406`9b7dc080 ffffc406`9b7dc080 00000000`00000001 : 0x1 ffffe08b`5fd2bef8 ffffe08b`5fd2ca58 : ffffc406`9b7dc080 ffffc406`9b7dc080 00000000`00000001 fffff801`78a8a868 : 0x9fda0 ffffe08b`5fd2bf00 ffffc406`9b7dc080 : ffffc406`9b7dc080 00000000`00000001 fffff801`78a8a868 00000000`00000000 : 0xffffe08b`5fd2ca58 ffffe08b`5fd2bf08 ffffc406`9b7dc080 : 00000000`00000001 fffff801`78a8a868 00000000`00000000 00000000`00000000 : 0xffffc406`9b7dc080 ffffe08b`5fd2bf10 00000000`00000001 : fffff801`78a8a868 00000000`00000000 00000000`00000000 00000000`00000000 : 0xffffc406`9b7dc080 ffffe08b`5fd2bf18 fffff801`78a8a868 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x1 ffffe08b`5fd2bf20 fffff801`78a29b31 : ffffc406`97515850 ffffe08b`5fd2c070 ffffc406`9b7dc080 00000000`00000000 : nt!DbgkpSendApiMessage+0xa4 ffffe08b`5fd2bf70 fffff801`784c9694 : ffffe08b`5fd2ca58 ffffe08b`5fd2ca58 ffffe08b`5fd2c120 00000000`00401000 : nt!DbgkForwardException+0xfa161 ffffe08b`5fd2c0f0 fffff801`7861186c : 00000000`00001000 ffffe08b`5fd2cb00 ffff8000`00000000 00000000`00000000 : nt!KiDispatchException+0x334 ffffe08b`5fd2c920 fffff801`7860d2bd : ffffc406`97ae8080 00000000`00000006 ffffe08b`00000000 ffffc406`00000000 : nt!KiExceptionDispatch+0x12c ffffe08b`5fd2cb00 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x43d SYMBOL_NAME: nt!_report_gsfailure+25 MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe STACK_COMMAND: .process /r /p 0xffffc4069b7dc080; .thread 0xffffc40697ae8080 ; kb BUCKET_ID_FUNC_OFFSET: 25 FAILURE_BUCKET_ID: 0xF7_MISSING_GSFRAME_nt!_report_gsfailure OS_VERSION: 10.0.19041.1 BUILDLAB_STR: vb_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {82d2c1b5-b0cb-60a5-9a5d-78c8c4284f84} Followup: MachineOwner --------- Это может из за запущенного вд ? Ладно ещё раз. Нет, то же самое. Что странно на синем экране вместо статусного кода ядерный адрес. Попозже попробую снова x32dbg, если будет такой крэш, значит после установки вд что то поменялось(появились DbgkpSendApiMessage()). Есть какие идеи ? --- Сообщение объединено, 8 мар 2025 в 16:54 --- Под олли ошибка исходная. --- Сообщение объединено, 8 мар 2025 в 16:59 --- * под x32dbg^ опечатка. --- Сообщение объединено, 8 мар 2025 в 17:07 --- KiCancelTimer небольшая процедура, пролог-эпилог и локали вроде с этим всё в порядке. Код (Text): .text:000000014021D3A0 ; __unwind { // __GSHandlerCheck .text:000000014021D3A0 mov r11, rsp .text:000000014021D3A3 push rbx .text:000000014021D3A4 push rbp .text:000000014021D3A5 push rsi .text:000000014021D3A6 push rdi .text:000000014021D3A7 push r12 .text:000000014021D3A9 sub rsp, 80h .text:000000014021D3B0 mov rax, cs:__security_cookie .text:000000014021D3B7 xor rax, rsp .text:000000014021D3BA mov [rsp+0A8h+var_30], rax .text:000000014021D3BF xor r10d, r10d .text:000000014021D3BF ; } // starts at 14021D3A0 .text:000000014021D3C2 .text:000000014021D3C2 loc_14021D3C2: ; DATA XREF: .rdata:000000014004A960↑o .text:000000014021D3C2 ; .rdata:000000014004A970↑o ... .text:000000014021D3C2 ; __unwind { // __GSHandlerCheck .text:000000014021D3C2 mov [r11+10h], r13 .text:000000014021D3C6 mov [r11-48h], r10 .text:000000014021D3CA xor sil, sil .text:000000014021D3CD mov [r11-74h], r10d .text:000000014021D3D1 movzx r12d, dl .text:000000014021D3D5 mov [rsp+0A8h+var_78], dl .text:000000014021D3D9 mov rbx, rcx .text:000000014021D3DC mov [r11+20h], r15 .text:000000014021D3E0 .text:000000014021D3E0 loc_14021D3E0: ; CODE XREF: KiCancelTimer+4A6↓j .text:000000014021D3E0 mov [rsp+0A8h+var_70], r10d .text:000000014021D3E5 lea r11, cs:140000000h .text:000000014021D3EC lock bts dword ptr [rbx], 7 .text:000000014021D3F1 jb loc_14021D710 .text:000000014021D3F7 .text:000000014021D3F7 loc_14021D3F7: ; CODE XREF: KiCancelTimer+391↓j .text:000000014021D3F7 test byte ptr [rbx+3], 0C0h .text:000000014021D3FB jz loc_14021D61B .text:000000014021D401 movzx eax, word ptr [rbx+38h] .text:000000014021D405 movzx r9d, byte ptr [rbx+2] .text:000000014021D40A mov rbp, gs:20h .text:000000014021D413 mov r15d, r9d .text:000000014021D416 mov [rsp+0A8h+var_6C], r10d .text:000000014021D41B mov r13, ds:rva KiProcessorBlock[r11+rax*8] .text:000000014021D423 movzx eax, word ptr [rbx+3Ah] .text:000000014021D427 lea rdi, [r9+10h] .text:000000014021D42B mov rcx, [rbp+84B8h] .text:000000014021D432 add r13, 3940h .text:000000014021D439 shl rax, 8 .text:000000014021D43D add rdi, rax .text:000000014021D440 shl rdi, 5 .text:000000014021D444 add rdi, r13 .text:000000014021D447 test rcx, rcx .text:000000014021D44A jnz loc_14042715C .text:000000014021D450 .text:000000014021D450 loc_14021D450: ; CODE XREF: KiCancelTimer+2CA↓j .text:000000014021D450 ; KiCancelTimer+209DC0↓j ... .text:000000014021D450 lock bts qword ptr [rdi], 0 .text:000000014021D456 jb loc_14021D63E .text:000000014021D45C movzx eax, byte ptr [rbx+3] .text:000000014021D460 test al, al .text:000000014021D462 js loc_14021D6C5 .text:000000014021D468 movzx r8d, word ptr [rbx+3Ah] .text:000000014021D46D lea rdx, [rbx+20h] .text:000000014021D471 mov rcx, [rdx] .text:000000014021D474 lea rsi, [r15+10h] .text:000000014021D478 mov eax, r8d .text:000000014021D47B lea rbp, [r15+10h] .text:000000014021D47F shl rax, 8 .text:000000014021D483 add rsi, rax .text:000000014021D486 mov eax, r8d .text:000000014021D489 xor rax, 1 .text:000000014021D48D shl rsi, 5 .text:000000014021D491 shl rax, 8 .text:000000014021D495 add rbp, rax .text:000000014021D498 mov rax, [rdx+8] .text:000000014021D49C shl rbp, 5 .text:000000014021D4A0 cmp [rcx+8], rdx .text:000000014021D4A4 jnz loc_140427458 .text:000000014021D4AA cmp [rax], rdx .text:000000014021D4AD jnz loc_140427458 .text:000000014021D4B3 mov [rax], rcx .text:000000014021D4B6 mov [rcx+8], rax .text:000000014021D4BA cmp rax, rcx .text:000000014021D4BD jz short loc_14021D533 .text:000000014021D4BF .text:000000014021D4BF loc_14021D4BF: ; CODE XREF: KiCancelTimer+270↓j .text:000000014021D4BF ; KiCancelTimer+20A074↓j ... .text:000000014021D4BF lock and qword ptr [rdi], 0 .text:000000014021D4C4 mov rcx, gs:20h .text:000000014021D4CD mov rdx, [rcx+84B8h] .text:000000014021D4D4 test rdx, rdx .text:000000014021D4D7 jnz loc_140427434 .text:000000014021D4DD .text:000000014021D4DD loc_14021D4DD: ; CODE XREF: KiCancelTimer+20A098↓j .text:000000014021D4DD ; KiCancelTimer+20A0A7↓j ... .text:000000014021D4DD mov eax, 0BFFFFF7Fh .text:000000014021D4E2 mov ecx, 0BFFFFFFFh .text:000000014021D4E7 .text:000000014021D4E7 loc_14021D4E7: ; CODE XREF: KiCancelTimer+368↓j .text:000000014021D4E7 test r12b, r12b .text:000000014021D4EA cmovz eax, ecx .text:000000014021D4ED lock and [rbx], eax .text:000000014021D4F0 mov sil, 1 .text:000000014021D4F3 .text:000000014021D4F3 loc_14021D4F3: ; CODE XREF: KiCancelTimer+27E↓j .text:000000014021D4F3 ; KiCancelTimer+28B↓j .text:000000014021D4F3 test dword ptr cs:PerfGlobalGroupMask+8, 20000h .text:000000014021D4FD jnz loc_14042745F .text:000000014021D503 .text:000000014021D503 loc_14021D503: ; CODE XREF: KiCancelTimer+20A0C2↓j .text:000000014021D503 ; KiCancelTimer+20A104↓j .text:000000014021D503 mov r15, [rsp+0A8h+arg_18] .text:000000014021D50B movzx eax, sil .text:000000014021D50F mov r13, [rsp+0A8h+arg_8] .text:000000014021D517 mov rcx, [rsp+0A8h+var_30] .text:000000014021D51C xor rcx, rsp ; StackCookie .text:000000014021D51F call __security_check_cookie .text:000000014021D524 add rsp, 80h .text:000000014021D52B pop r12 .text:000000014021D52D pop rdi .text:000000014021D52E pop rsi .text:000000014021D52F pop rbp .text:000000014021D530 pop rbx .text:000000014021D531 retn .text:000000014021D531 ; } // starts at 14021D3C2 --- Сообщение объединено, 8 мар 2025 в 17:14 --- Я вот что подумал. А не может ли KiCancelTimer() вкинуть фаулт, который локально обработается, где и портится контекст и это не видит вд ?
Честно говоря, вообще не уверен, что проблема именно в KiCancelTimer. То, что в нём упало, скорее следствие чего-то, что произошло где-то раньше (возможно даже в другом процессе). Потому что тут странно: в первом дампе у тебя упало в контексте отладчика, во втором - в контексте самого процесса. Явно где-то баг в реализации отладки в ядре: где-то что-то портится, а потом это рандомно всплывает в разных местах. Вот например: во втором дампе у тебя вылетел PF, ядро его успешно поймало, отдало отладчику, дальше какой-то мусор, снова отладчик - и падаем на FastMutex'е. Ну явно он испортился не прямо сейчас, а где-то задолго (возможно, как раз в том мусоре между DkbgpSendApiMessage и DbgkpQueueMessage). --- Сообщение объединено, 8 мар 2025 в 23:25 --- А вот этот вылетевший PageFault (который самый первый, в самом низу стактрейса) - он где? Это PF из юзермода или уже где-то в ядре? --- Сообщение объединено, 8 мар 2025 в 23:42 --- Кстати, в последнем дампе упало на освобождении вот этого мьютекса (это из десятки 19041, как у тебя): Тут же нечему падать - значит, кто-то испортил сам мьютекс.
HoShiMin > вот этот вылетевший PageFault (который самый первый, в самом низу стактрейса) - он где? Это PF из юзермода или уже где-то в ядре? Это уже сложная ошибка, думаю лучше разобрать тот с шедулером, тем более он стабильно воспроизводится. Разбирать пэйджфаулт это наверно нет смысла. В крэшдамп сохраняется состояние ос на момент падения, наверно нет всяких трасс. Как то очень странно, разве такая трудность потратить пять минут на проверку, воспроизводится ли баг на другом компе.
Дык нету десятки, её надо качать, ставить - у меня только виртуалка с одиннадцатой. И есть коллекция ядер от разных систем - вот там и смотрю. А вот по планировщику: падаем здесь (в KiSwapThread): Опять же, тут нечему падать, если где-то не испортился сам указатель на oldThread (а он как раз испортился - это ведь он лежит в rsi). Но я глянул в KiCancelTimer - там rsi кладётся на стек и восстанавливается нормально, стек не портится. И при этом, в KiCancelTimer много логики, завязанной на содержимом самого таймера - будь он изначально невалидным, неминуемо падало бы в нём. Собсна, всё как ты и говорил, но я не вижу ни одной причины тут падать... Эксепшны - тоже вряд ли, там нет try..except'ов.
Есть ли мысли как это решить ? Брать второй ноут и вд отлаживать это край, в принципе я этот взял чтобы разобрать проблему майкла. Тем более я не знаю как это сделать.
Так а в чём проблема настроить ядерную отладку на виртуалке? Настраивай через KDNET: отладка будет по UDP, без COM-портов. Настраивается буквально в три-четыре команды. Вот инструкция: https://learn.microsoft.com/en-us/w...ger/setting-up-a-network-debugging-connection Пункты про busparams можно пропустить, заведётся и без них. В итоге всё сведётся к этим командам на виртуалке: Код (Text): bcdedit.exe /debug on bcdedit.exe /dbgsettings net hostip:123.123.123.123 port:50000 …где 123.123.123.123 - адрес хоста, а 50000 - порт, на котором будет слушать отладчик на хосте (50000 - дефолтный). Вторая команда выдаст тебе ключик, скопируй только сам ключик, без key=. Дальше на хосте запускаешь WinDbg (возьми в MS Store), там File -> Attach to kernel -> Выбираешь KDNET, вставляешь в поле свой ключик с виртуалки, ставишь порт 50000 и запускаешь. Теперь отладчик ждёт подключений: важно, что не отладчик подключается к виртуалке, а виртуалка к отладчику - отключи на хосте и виртуалке файрволл, чтобы виртуалке никто не мешал. И всё, можно идти в ребут, и будет у тебя нормальная ядерная отладка.
Большое спасибо! Полный аварийный дамп весит примерно пол гб, сеть через мб, в принципе я могу попробовать его кудато загрузить. --- Сообщение объединено, 9 мар 2025 в 02:14 --- Вот вроде загрузилось. Это с последнего крэша где стабильный адрес, я просто немного запутался запуская эти отладчики
Может поэкспериментировать с самими инструкциями на isa уровне ? Почему крэш именно на popfd, если во флажках ничего нет необычного: efl=00010246 Причём крэш только при пошаговой отладке, может попробовать потрейсить ? --- Сообщение объединено, 9 мар 2025 в 10:55 --- Не падает trace into. --- Сообщение объединено, 9 мар 2025 в 10:59 --- Если остановиться на popfd, EF: 0x214 TF -> 1, 0x314 посмотреть что будет, снова исходный крэш. Но это при нажатии f8, возможно при run не упадёт, так как всё дело в отладочных сервисах. --- Сообщение объединено, 9 мар 2025 в 11:08 --- Попробовать собрать аналог в 64 ?
Попробуй и в x64, и попробуй уменьшить исходный пример (в идеале оставить только popfd). Например, падает ли на любом popfd или только на popfd с 0x214 на 0x314.
Сейчас посмотрим. --- Сообщение объединено, 9 мар 2025 в 12:58 --- Код (Text): EP proc push 0 popfd bsod. --- Сообщение объединено, 9 мар 2025 в 13:00 --- Попробовать как то флажки по другому загрузить, iret ? --- Сообщение объединено, 9 мар 2025 в 13:07 --- Код (Text): EP proc push 0 push cs push offset stub iretd упало на iret. Тот же самый #AV. Что то я понять не могу, это не контекст. Попробовать вставить префиксы в инструкцию ? --- Сообщение объединено, 9 мар 2025 в 13:24 --- x64dbg pushfq popfq bsod. --- Сообщение объединено, 9 мар 2025 в 13:28 --- Такого я никогда не видел, это какое то чудо. Попробовать контекст прогрузить, ntcontinue ? --- Сообщение объединено, 9 мар 2025 в 13:51 --- Код (Text): EP proc Local Ctx[512]:byte mov CONTEXT.ContextFlags[Ctx],CONTEXT_FULL invoke GetThreadContext, -2, addr Ctx invoke ZwContinue, addr Ctx, 0 Не падает. --- Сообщение объединено, 9 мар 2025 в 14:25 --- Код (Text): EP proc push 0 push cs push offset stub db 0f0h, 0f0h, 0f0h iretd - префикс блокировки, возникает фаулт ничего не крэшит.
Вероятно, упадёт с RtlRestoreContext вместо NtContinue --- Сообщение объединено, 9 мар 2025 в 14:27 --- А бсодит в итоге в тех же местах в ядре? Где-то в DbgkpQueueMessage?
HoShiMin, Нет, адрес тот же в шедулере. Посмотрю сейчас RtlRestoreContext нужно глянуть прототип, я не помню её. --- Сообщение объединено, 9 мар 2025 в 15:00 --- RtlRestoreContext не билдится, этого экспорта нет в ntdll, kernel32, kernelbase. На мсдн нет версии системы: Эта апи наверно была в младших версиях. Не удивительно почему я её не помню. --- Сообщение объединено, 9 мар 2025 в 15:22 --- github/nt5src/..ia64 Эта апи есть, но там нет никаких сервисных вызовов. Это какая то заглушка правящая структуры.
