в общем subj. запустите make-all-and-run.bat и покажите свой log. особенно интересует XP, Висла, Server 2008, и разные виртуалки типа Virtual PC
Код (Text): BugCheck 100000D1, {45b0, ff, 0, f580aa75} Probably caused by : Syser.sys ( Syser+aa75 ) Followup: MachineOwner --------- kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If kernel debugger is available get stack backtrace. Arguments: Arg1: 000045b0, memory referenced Arg2: 000000ff, IRQL Arg3: 00000000, value 0 = read operation, 1 = write operation Arg4: f580aa75, address which referenced memory Debugging Details: ------------------ READ_ADDRESS: 000045b0 CURRENT_IRQL: ff FAULTING_IP: Syser+aa75 f580aa75 8bb1580a0000 mov esi,dword ptr [ecx+0A58h] CUSTOMER_CRASH_COUNT: 2 DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO BUGCHECK_STR: 0xD1 PROCESS_NAME: PeterFerrie.exe LAST_CONTROL_TRANSFER: from f582e159 to f580aa75 STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. 822d2fc8 f582e159 19ca7000 00000023 00000023 Syser+0xaa75 822d2fd4 00000000 0000003b 001300d4 00000000 Syser+0x2e159 STACK_COMMAND: kb FOLLOWUP_IP: Syser+aa75 f580aa75 8bb1580a0000 mov esi,dword ptr [ecx+0A58h] SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: Syser+aa75 FOLLOWUP_NAME: MachineOwner MODULE_NAME: Syser IMAGE_NAME: Syser.sys DEBUG_FLR_IMAGE_TIMESTAMP: 46aaa3f8 FAILURE_BUCKET_ID: 0xD1_Syser+aa75 BUCKET_ID: 0xD1_Syser+aa75 Followup: MachineOwner ---------
wsd охренительный способ борьбы с сизером. правда, так и не ясно, что именно ему не нравится. у меня под айсом все нормально воркается и уж на BSOD никак не высаживает... странно... попробуй потрасировать PeterFerrie.exe под олькой или самим сизером. SED.exe - это примитивный отладчик. меня интересует именно работа PeterFerrie.exe (да, когда будешь трассировать закомментируй push -1/popfd, т.к. они при этом на фиг не нужны), и еще - поскольку PeterFerrie.exe "исторически" возник в результате дописывания примера кода, присланного мне Peter'ом Ferrie (ну что работает в ms), то push -1 сие его идея, мной не одобренная, но править было лень. у меня усе работало.
Крис олька RVA 0x1cfh MOV EAX,DWORD PTR DS:[EAX] стопориться а сисер прям на его загрузке бсодит грузил 3 раза Код (Text): BugCheck 100000D1, {4001c0, ff, 1, f584ef50} Probably caused by : Syser.sys ( Syser+4ef50 ) Followup: MachineOwner --------- kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If kernel debugger is available get stack backtrace. Arguments: Arg1: 004001c0, memory referenced Arg2: 000000ff, IRQL Arg3: 00000001, value 0 = read operation, 1 = write operation Arg4: f584ef50, address which referenced memory Debugging Details: ------------------ WRITE_ADDRESS: 004001c0 CURRENT_IRQL: ff FAULTING_IP: Syser+4ef50 f584ef50 880a mov byte ptr [edx],cl CUSTOMER_CRASH_COUNT: 5 DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT BUGCHECK_STR: 0xD1 PROCESS_NAME: PeterFerrie.exe LAST_CONTROL_TRANSFER: from f5805f0e to f584ef50 STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. 822f6fb4 f5805f0e f591bd78 f591bef8 822f6fd4 Syser+0x4ef50 822f6fb8 f591bd78 f591bef8 822f6fd4 f591be78 Syser+0x5f0e 822f6fbc f591bef8 822f6fd4 f591be78 f582e00d Syser+0x11bd78 822f6fc0 822f6fd4 f591be78 f582e00d 804fb668 Syser+0x11bef8 822f6fc4 f591be78 f582e00d 804fb668 00000023 0x822f6fd4 822f6fd4 00000000 00000030 c0300004 c0001000 Syser+0x11be78 STACK_COMMAND: kb FOLLOWUP_IP: Syser+4ef50 f584ef50 880a mov byte ptr [edx],cl SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: Syser+4ef50 FOLLOWUP_NAME: MachineOwner MODULE_NAME: Syser IMAGE_NAME: Syser.sys DEBUG_FLR_IMAGE_TIMESTAMP: 46aaa3f8 FAILURE_BUCKET_ID: 0xD1_W_Syser+4ef50 BUCKET_ID: 0xD1_W_Syser+4ef50 Followup: MachineOwner ---------
wsd не, ну понятно, что ольга стопиться, но дело не в ней, а в том, что ядро винды не снимает TF бит на фаултах и при выходе из seh-обработчика, обрабатывающего исключение доступа, функция ntdll!KiUserExceptionDispatcher вызывает ntdll!NtRaiseException, которая в свою очередь вызывает одноименный ядерный сервис для восстановления регистрового контекста и передачи управления в том место, откуда оно было прервано исключением, но поскольку TF флаг в контексте не сброшен, то при его восстановлении тут же генериться еще одно исключение (уже внутри ядра) и ядро повторно вызывает ntdll!KiUserExceptionDispatcher, так же не сбрасывая TF-флаг. процессор выполняет первую инструкцию функции ntdll!KiUserExceptionDispatcher, после чего генерит трассировочное прерывание, подхватываемое ядром, которое на этот раз наконец-то сбрасывает TF-флаг и вызываает ntdll!KiUserExceptionDispatcher _еще_ один раз, чтобы она обрабатала исключение в самой себе. если seh-обработчик написан корректно и готов ловить неожиданные исключения, то все ок (исключения реентерабельны), но... вот ольга на этом чисто конкретно обламывается и не хочет продолжать выполнение программы, хотя все остальные отладчики, известные мне, правят это путем принудительного сброса TF в регистровом контексте при ловле фаулта. кстати, крэш сусера может возникать из-за неестественных размеров файла PeterFerrie.exe. попробуй пересобрать его со следующими ключами линкера: link.exe %NIK%.obj /ENTRY:nezumi /SUBSYSTEM:CONSOLE KERNEL32.LIB
Код (Text): Microsoft Windows [‚ҐабЁп 6.0.6000] SED [Simple Experimental Debugger] -CREATE_THREAD_DEBUG_EVENT -LOAD_DLL_DEBUG_EVENT -LOAD_DLL_DEBUG_EVENT ->BREAKPOINT [(80000003h) @0778A2EA8h] EIP = 778A2EA9h | ESP = 0012FB18h | EFLAGS = 00000246h ->ACCESS VIOLATION [(C0000005h) @0004001CFh] EIP = 004001CFh | ESP = 0012FF9Ch | EFLAGS = 00254FD7h ->SINGLE STEP [(80000004h) @0778C0E89h] EIP = 778C0E89h | ESP = 0012FCACh | EFLAGS = 00244AD7h ->SINGLE STEP [(80000004h) @0004001D2h] EIP = 004001D2h | ESP = 0012FF9Ch | EFLAGS = 00244ED7h ->ILLEGAL_INSTRUCTION [(C000001Dh) @0004001D2h] EIP = 004001D2h | ESP = 0012FF9Ch | EFLAGS = 00254FD7h ->SINGLE STEP [(80000004h) @0778C0E89h] EIP = 778C0E89h | ESP = 0012FCB4h | EFLAGS = 00244AD7h ->SINGLE STEP [(80000004h) @0004001D5h] EIP = 004001D5h | ESP = 0012FF9Ch | EFLAGS = 00244ED7h ->SINGLE STEP [(80000004h) @0004001D6h] EIP = 004001D6h | ESP = 0012FF9Ch | EFLAGS = 00244ED7h ->BREAKPOINT [(80000003h) @0004001D6h] EIP = 004001D7h | ESP = 0012FF9Ch | EFLAGS = 00244FD7h ->SINGLE STEP [(80000004h) @000400215h] EIP = 00400215h | ESP = 0012FF9Ch | EFLAGS = 00244ED7h -EXIT PROCESS DEBUG EVENT ExitCode: 0000h Это виста
SWR пасиб! значит, и в висте этот баг есть. забавно ->ACCESS VIOLATION [(C0000005h) @0004001CFh] EIP = 004001CFh | ESP = 0012FF9Ch | EFLAGS = 00254FD7h смотри на EFLAGS = 00254FD7h, бит трассировки _взведен_, а ведь не должен...
Крис пересобрал с нормальными параметрами и сизер нормально грузит и отрабатывает её без бсода. Крис а какие версии у тебя по поводу бсодов не из под сизера, а по make-all-and-run.bat, с просто инсталлированным сизером? сам-то сизер её нормально отрабатывает
Крис я наверно не совсем корректно сформулировал предыдущий вопрос 1. если сисер активен в системе то PeterFerrie.exe БСОДит 2. если PeterFerrie.exe грузить через сизоровский лоадер, то не БСОДит сисер 1.93
wsd да я понял. описал разработчикам. пускай ищут бага в сисере. а бсодит потому что пионерский рип айса. айс хотя бы хакеры писали... PeterFerrie.exe собран стандартным ms линкером и формально нарушает только два правила: выравнивание страниц и в ms-dos стабе там неверно указаны размеры файла (все равно его никто не проверяет), ну а что касается выравнивания - то в NT используется один загрузчик для драйверов и pe, а для драйверов такое выравнивание допустимо. в любом случае, бсод вылазить не должен. вероятно, систер обращатся к страницам pe-файла, которых нет ибо выравнивание такое, что файл получается очень компактным и это с честным компилятором и штатным линкером
Крис вот кстати с отключенным сисером ХР2 Код (Text): Microsoft Windows XP [‚ҐабЁп 5.1.2600] SED [Simple Experimental Debugger] -CREATE_THREAD_DEBUG_EVENT -LOAD_DLL_DEBUG_EVENT -LOAD_DLL_DEBUG_EVENT ->BREAKPOINT [(80000003h) @07C901230h] EIP = 7C901231h | ESP = 0012FB20h | EFLAGS = 00000202h ->ACCESS VIOLATION [(C0000005h) @0004001CFh] EIP = 004001CFh | ESP = 0012FFBCh | EFLAGS = 00254FD7h ->SINGLE STEP [(80000004h) @07C90EAF0h] EIP = 7C90EAF0h | ESP = 0012FCCCh | EFLAGS = 00244ED7h ->SINGLE STEP [(80000004h) @0004001D2h] EIP = 004001D2h | ESP = 0012FFBCh | EFLAGS = 00240ED7h ->ILLEGAL_INSTRUCTION [(C000001Dh) @0004001D2h] EIP = 004001D2h | ESP = 0012FFBCh | EFLAGS = 00250FD7h ->SINGLE STEP [(80000004h) @07C90EAF0h] EIP = 7C90EAF0h | ESP = 0012FCD4h | EFLAGS = 00240ED7h ->SINGLE STEP [(80000004h) @0004001D5h] EIP = 004001D5h | ESP = 0012FFBCh | EFLAGS = 00240ED7h ->SINGLE STEP [(80000004h) @0004001D6h] EIP = 004001D6h | ESP = 0012FFBCh | EFLAGS = 00240ED7h ->BREAKPOINT [(80000003h) @0004001D6h] EIP = 004001D7h | ESP = 0012FFBCh | EFLAGS = 00240FD7h ->SINGLE STEP [(80000004h) @000400215h] EIP = 00400215h | ESP = 0012FFBCh | EFLAGS = 00240ED7h -EXIT PROCESS DEBUG EVENT ExitCode: 0000h
Windows XP Professional x64 Service Pack 2 "The application failed to initialize properly (0xc0000018)." Код (Text): Microsoft Windows [Version 5.2.3790] SED [Simple Experimental Debugger] -CREATE_THREAD_DEBUG_EVENT -UNLOAD_DLL_DEBUG_EVENT -LOAD_DLL_DEBUG_EVENT -UNLOAD_DLL_DEBUG_EVENT -LOAD_DLL_DEBUG_EVENT -UNLOAD_DLL_DEBUG_EVENT -UNLOAD_DLL_DEBUG_EVENT ->UNKNOWN [(C0000018h) @07D64A79Eh] EIP = 7D64A79Eh | ESP = 0012FCBCh | EFLAGS = 00000246h ->UNKNOWN [(C0000018h) @07D64A79Eh] EIP = 7D64A79Eh | ESP = 0012FCBCh | EFLAGS = 00000246h -EXIT PROCESS DEBUG EVENT ExitCode: 0080h
всем спасибо. баг подтвержден. впрочем, я не первый кто его обнаружил. сейчас имел переписку с парнем из ms, баг имеет место быть и никто его фиксить не собирается... и он не один. баг в смысле. там их до хрена. в ядре в смысле... вокруг обработчика исключений...
