Цитата NickM:
|
У Вас не подключены символы; »
|
В программе WinDbg в пункте "Symbol file path..." указал путь
https://msdl.microsoft.com/download/symbols.
Этого достаточно?
Цитата NickM:
При простом анализе видно это:
MODULE_NAME: memory_corruption »
|
Но все равно, даже после подключения символов, "мой" отчет WinDbg не такой как у вас.
В моем отчете нету фразы "MODULE_NAME: memory_corruption".
Вот что сейчас у меня выдает WinDbg:
Скрытый текст
Код:
Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [F:\Erin_works\СанТехКом\55. Задания\2023-01-30. 08-00. Синий экран\MEMORY_2023-01-30.DMP]
Kernel Bitmap Dump File: Only kernel address space is available
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred https://msdl.microsoft.com/download/symbols
Symbol search path is: https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 17763 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 17763.1.amd64fre.rs5_release.180914-1434
Machine Name:
Kernel base = 0xfffff807`52e16000 PsLoadedModuleList = 0xfffff807`5322f430
Debug session time: Mon Jan 30 08:19:45.953 2023 (UTC + 3:00)
System Uptime: 2 days 23:48:34.823
Loading Kernel Symbols
...............................................................
................................................................
................................................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00000000`031fa018). Type ".hh dbgerr001" for details
Loading unloaded module list
...................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1E, {ffffffffc0000005, fffff80eaa782ba5, 1, c0000225}
Probably caused by : Wof.sys ( Wof!WofAcquireFileSystemRundown+1 )
Followup: MachineOwner
---------
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80eaa782ba5, The address that the exception occurred at
Arg3: 0000000000000001, Parameter 0 of the exception
Arg4: 00000000c0000225, Parameter 1 of the exception
Debugging Details:
------------------
WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
00000000c0000225
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - <Unable to get error code text>
FAULTING_IP:
Wof!WofAcquireFileSystemRundown+1
fffff80e`aa782ba5 3000 xor byte ptr [rax],al
EXCEPTION_PARAMETER1: 0000000000000001
EXCEPTION_PARAMETER2: 00000000c0000225
BUGCHECK_STR: 0x1E_c0000005_W
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: avp.exe
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre
TRAP_FRAME: 0000000000001000 -- (.trap 0x1000)
Unable to read trap frame at 00000000`00001000
LAST_CONTROL_TRANSFER: from fffff807530188d9 to fffff80752fceea0
STACK_TEXT:
ffffee0f`d8bbeb58 fffff807`530188d9 : 00000000`0000001e ffffffff`c0000005 fffff80e`aa782ba5 00000000`00000001 : nt!KeBugCheckEx
ffffee0f`d8bbeb60 fffff807`52fe2902 : 00000000`00000000 ffffee0f`d8bbf3f0 00000000`00001000 00000000`c0000225 : nt!KiDispatchException+0x180d89
ffffee0f`d8bbf210 fffff807`52fde4e8 : ffff8684`19600340 ffffee0f`d8bbf868 00000000`00000003 00000000`00002970 : nt!KiExceptionDispatch+0xc2
ffffee0f`d8bbf3f0 fffff80e`aa782ba5 : ffffee0f`d8bbf610 fffff80e`aa7818fd ffffbc0b`fffeee60 ffffbc0c`09140b28 : nt!KiPageFault+0x428
ffffee0f`d8bbf580 ffffee0f`d8bbf610 : fffff80e`aa7818fd ffffbc0b`fffeee60 ffffbc0c`09140b28 00000000`00000002 : Wof!WofAcquireFileSystemRundown+0x1
ffffee0f`d8bbf588 fffff80e`aa7818fd : ffffbc0b`fffeee60 ffffbc0c`09140b28 00000000`00000002 ffffee0f`d8bbf6a0 : 0xffffee0f`d8bbf610
ffffee0f`d8bbf590 fffff80e`a98dfca2 : ffffbc0c`09140b28 ffffee0f`d8bbf6e0 ffffee0f`00000001 00000000`00000000 : Wof!WofPreReadCallback+0x6d
ffffee0f`d8bbf650 fffff80e`a98d7389 : ffffee0f`d8bbf890 ffffee0f`d8bbfc00 00000000`00000003 fffff80e`00000000 : FLTMGR!FltpPerformPreCallbacksWorker+0x4d2
ffffee0f`d8bbf760 fffff80e`a98d6f6c : ffffbc0c`0b29d3b0 ffffee0f`d8bc0000 ffffee0f`d8bba000 ffffee0f`d8bbf890 : FLTMGR!FltpPerformPreCallbacks+0x79
ffffee0f`d8bbf7b0 fffff80e`a98d66f0 : ffffbc0c`091af010 00000000`00060043 ffffbc0c`091af010 ffffee0f`d8bbf8a0 : FLTMGR!FltpPassThroughInternal+0x8c
ffffee0f`d8bbf7e0 fffff80e`a98d612e : ffff8684`19ec07a0 00000000`00000000 ffff9c80`030479c0 00000000`00000000 : FLTMGR!FltpPassThrough+0x510
ffffee0f`d8bbf870 fffff807`52e43029 : ffffbc0c`091af010 fffff807`52e2232f ffffbc0c`05dff350 00000000`00000000 : FLTMGR!FltpDispatch+0x9e
ffffee0f`d8bbf8d0 fffff807`52e22218 : ffffbc0b`ffed1cd0 ffffbc0c`091af010 ffffbc0c`0b29d3e0 ffffbc0c`0b29d4a0 : nt!IofCallDriver+0x59
ffffee0f`d8bbf910 fffff807`52f395a9 : ffffbc0c`0b29d390 ffffbc0c`0b29d3b0 ffffbc0c`0b29d3f0 ffffbc0c`0b29d3e0 : nt!IoPageReadEx+0x188
ffffee0f`d8bbf960 fffff807`52e53b3d : 00000000`00000003 ffffee0f`d8bbf9f0 ffffee0f`d8bbfb58 ffff9a4d`00001dc0 : nt!MiIssueHardFaultIo+0xc1
ffffee0f`d8bbf9b0 fffff807`52e6ad5f : ffff8000`00000000 00000000`c0033333 00000000`7701a835 00000000`00000000 : nt!MiIssueHardFault+0x3ed
ffffee0f`d8bbfa60 fffff807`52fde403 : ffffbc0c`06f9c080 00000000`04981820 ffffee0f`d8bbfc80 ffffbc0c`0b2f7b60 : nt!MmAccessFault+0x32f
ffffee0f`d8bbfc00 00000000`7701a835 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x343
00000000`0693cc10 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7701a835
STACK_COMMAND: kb
FOLLOWUP_IP:
Wof!WofAcquireFileSystemRundown+1
fffff80e`aa782ba5 3000 xor byte ptr [rax],al
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: Wof!WofAcquireFileSystemRundown+1
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Wof
IMAGE_NAME: Wof.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 7d65a03b
BUCKET_ID_FUNC_OFFSET: 1
FAILURE_BUCKET_ID: 0x1E_c0000005_W_Wof!WofAcquireFileSystemRundown
BUCKET_ID: 0x1E_c0000005_W_Wof!WofAcquireFileSystemRundown
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x1e_c0000005_w_wof!wofacquirefilesystemrundown
FAILURE_ID_HASH: {0c3d85ce-ec4d-9d2f-d934-09500386df5c}
Followup: MachineOwner
---------
Почему такая сильная разница в отчетах WinDbg?
Чей-то WinDbg сильно врет.
И куда дальше копать? Где искать причину синего экрана?
