I recently encountered the problem of calling FwpmEngineOpen method on windows 11 22h2 system causing BSOD. Not every windows 11 22h2 laptop will experience this problem. But the laptop with the problem, it reproduces the problem every time.
I tried to reinstall windows 11 21h2 on the faulty device. Failed to reproduce the BSOD problem. Then upgrade to 22H2 using the latest windows 11 ISO, which can reproduce the BSOD. So I guess the problem only exists at windows 11 22H2.
The dump is:
Microsoft (R) Windows Debugger Version 10.0.22621.382 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\melon\Desktop\BSOD\22017068\121222-10750-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
************* Path validation summary **************
Response Time (ms) Location
Deferred SRV*E:\WindowsPDB*http://msdl.microsoft.com/download/symbols
OK C:\Users\melon\Desktop\BSOD\06202019\win8_release
Symbol search path is: SRV*E:\WindowsPDB*http://msdl.microsoft.com/download/symbols;C:\Users\melon\Desktop\BSOD\06202019\win8_release
Executable search path is:
Windows 10 Kernel Version 22621 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Machine Name:
Kernel base = 0xfffff802`61200000 PsLoadedModuleList = 0xfffff802`61e13410
Debug session time: Mon Dec 12 17:46:26.125 2022 (UTC + 8:00)
System Uptime: 0 days 1:16:03.795
Loading Kernel Symbols
...............................................................
................................................................
................................................................
..........................................
Loading User Symbols
Loading unloaded module list
........................
For analysis of this file, run !analyze -v
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
BugCheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: fffff8025d4c4e70
Arg3: ffffe48d45e4bfb0
Arg4: fffff802614bea11
Debugging Details:
------------------
*** WARNING: Unable to verify timestamp for apegw.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 2217
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 3200
Key : Analysis.Init.CPU.mSec
Value: 2671
Key : Analysis.Init.Elapsed.mSec
Value: 114150
Key : Analysis.Memory.CommitPeak.Mb
Value: 113
FILE_IN_CAB: 121222-10750-01.dmp
DUMP_FILE_ATTRIBUTES: 0x1008
Kernel Generated Triage Dump
BUGCHECK_CODE: 7f
BUGCHECK_P1: 8
BUGCHECK_P2: fffff8025d4c4e70
BUGCHECK_P3: ffffe48d45e4bfb0
BUGCHECK_P4: fffff802614bea11
STACK_OVERFLOW: Stack Limit: ffffe48d45e4c000. Use (kF) and (!stackusage) to investigate stack usage.
STACKUSAGE_FUNCTION: The function at address 0xfffff802731d1809 was blamed for the stack overflow. It is using 13888 bytes of stack.
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: SA2.0QuestUpda
STACK_TEXT:
ffffe48d`45e4bfb0 fffff802`614c20c4 : 00000000`00000000 0b030000`00000157 00000000`00000021 00000521`00000521 : nt!KiDeferredReadySingleThread+0x41
ffffe48d`45e4c380 fffff802`614b39c2 : 000005c7`000005c7 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiExitDispatcher+0x184
ffffe48d`45e4c720 fffff802`614b3294 : ffffa989`00000000 ffffa989`2a2a9768 00000000`0000000c 00000000`00000000 : nt!KeInsertPriQueue+0x5a2
ffffe48d`45e4c7b0 fffff802`619dbb56 : 00000000`00000001 00000000`00000000 00000000`00000000 ffff8082`8302d370 : nt!ExQueueWorkItem+0x164
ffffe48d`45e4c810 fffff802`61957e4f : 00000000`00000001 00000000`00000000 ffff8082`8302d370 00000000`00000000 : nt!ExpWnfStartKernelDispatcher+0x3e
ffffe48d`45e4c840 fffff802`61955e16 : ffff8082`8302d300 00000000`00000000 ffffe48d`00000001 00000000`00000000 : nt!ExpWnfNotifyNameSubscribers+0x177
ffffe48d`45e4c8b0 fffff802`61955b4e : 00000605`00000605 00000000`00000000 000002e5`22f25990 000002e5`22eff960 : nt!ExpNtUpdateWnfStateData+0x2ba
ffffe48d`45e4c9c0 fffff802`6163d1e8 : ffff8082`84a8e000 fffff802`614d2615 ffffffff`ffffffff 00000000`0000001c : nt!NtUpdateWnfStateData+0x2e
ffffe48d`45e4ca10 fffff802`6162dc50 : fffff802`618a4736 00000000`00000001 00000000`00000001 00000000`00000006 : nt!KiSystemServiceCopyEnd+0x28
ffffe48d`45e4cc18 fffff802`618a4736 : 00000000`00000001 00000000`00000001 00000000`00000006 00000000`00000000 : nt!KiServiceLinkage
ffffe48d`45e4cc20 fffff802`619e378c : ffff8082`94580e00 fffff802`00000000 ffff8082`00000006 00000000`00002758 : nt!PspChargeProcessWakeCounter+0x366
ffffe48d`45e4ccd0 fffff802`61a8e1fe : 00000000`00000000 ffffa989`3f07cdf0 ffff8082`94659b50 00000000`00000000 : nt!PsChargeProcessWakeCounter+0x4c
ffffe48d`45e4cd20 fffff802`618a5ce1 : ffff8082`94659b00 ffffa989`3f330830 ffffa989`3238f940 00000000`00000000 : nt!AlpcpCompleteDispatchMessage+0x1e80fe
ffffe48d`45e4cde0 fffff802`618a5a12 : ffffa989`3238f940 ffffa989`3f07cdf0 00000000`00000000 00000000`00000000 : nt!AlpcpDispatchNewMessage+0x291
ffffe48d`45e4ce40 fffff802`618a9480 : ffffe48d`45e4cff0 ffff8082`900ff000 ffff8082`944094f0 fffff802`614be800 : nt!AlpcpSendMessage+0x922
ffffe48d`45e4cf70 fffff802`618a6c99 : ffffa989`3f330830 00000000`00220000 ffff8082`900ff000 ffff8082`944094f0 : nt!AlpcpProcessSynchronousRequest+0x330
ffffe48d`45e4d090 fffff802`6163d1e8 : ffffa989`39273080 ffffe48d`45e4d240 ffffe48d`45e4d378 ffffe48d`45e4d168 : nt!NtAlpcSendWaitReceivePort+0x1d9
ffffe48d`45e4d150 fffff802`6162dc50 : fffff802`62c5bcfe ffff8082`900ff000 00000000`00000000 ffff8082`94409480 : nt!KiSystemServiceCopyEnd+0x28
ffffe48d`45e4d358 fffff802`62c5bcfe : ffff8082`900ff000 00000000`00000000 ffff8082`94409480 ffff8082`944095f8 : nt!KiServiceLinkage
ffffe48d`45e4d360 fffff802`62c5bc12 : 00000000`00001000 ffff8082`94409480 ffffe48d`45e4d600 fffff802`62c4a0d0 : msrpc!LRPC_BASE_CCALL::DoSendReceive+0x72
ffffe48d`45e4d3d0 fffff802`62c5c5fb : 00000000`00000000 ffffe48d`45e4d470 00000000`00000000 fffff802`62c434f0 : msrpc!LRPC_BASE_CCALL::SendReceive+0x52
ffffe48d`45e4d400 fffff802`62c42435 : ffffe48d`45e4d6c0 00000000`00000000 fffff802`62c434f0 00000000`00000000 : msrpc!NdrSendReceive+0x47
ffffe48d`45e4d430 fffff802`62c42313 : 00000000`00000000 fffff802`62c434f0 fffff802`00000007 ffffe48d`45e4d460 : msrpc!NdrpClientCall3+0xf5
ffffe48d`45e4d680 fffff802`62c6e589 : 00000000`00000000 ffffa989`39273080 00000000`00000000 ffff8082`9460d550 : msrpc!NdrClientCall3+0x93
ffffe48d`45e4da20 fffff802`62c6e3c5 : ffff8082`9392cb20 ffff8082`94610100 00000000`00000000 00000000`00000000 : msrpc!EP_LOOKUP_DATA::LookupNextChunk+0x11d
ffffe48d`45e4daf0 fffff802`62c6e8f5 : 00000000`00000000 00000000`00000000 ffff8082`94610100 ffffe48d`45e4dd70 : msrpc!EP_LOOKUP_DATA::ResolveEndpoint+0x135
ffffe48d`45e4db80 fffff802`62c6e86e : ffff8082`94610070 00000000`00000000 ffff8082`94610100 fffff802`62c6e198 : msrpc!ResolveEndpointWithEpMapper+0x6d
ffffe48d`45e4dbe0 fffff802`62c6e0d1 : ffff8082`94610070 00000000`00000000 ffff8082`94610100 fffff802`614c8d40 : msrpc!ResolveEndpointIfNecessary+0xa6
ffffe48d`45e4dc60 fffff802`62c6dfab : 00000000`00000000 00000000`00000000 ffff8082`94610070 00000000`00000000 : msrpc!LRPC_BASE_BINDING_HANDLE::SubmitResolveEndpointRequest+0xcd
ffffe48d`45e4dcf0 fffff802`62c690a1 : 00000000`00000000 ffff8082`94610070 fffff802`642cd000 ffff8082`9464bd90 : msrpc!LRPC_BASE_BINDING_HANDLE::ResolveEndpoint+0xeb
ffffe48d`45e4dd70 fffff802`62c68717 : ffff8082`94610070 ffff8082`94610070 ffffe48d`45e4de39 00000000`00000000 : msrpc!LRPC_BASE_BINDING_HANDLE::DriveStateForward+0x2a1
ffffe48d`45e4ddd0 fffff802`62c6b22d : 00000000`00000000 00000000`00000000 00000000`00000000 ffff8082`9464bd90 : msrpc!LRPC_FAST_BINDING_HANDLE::Bind+0x137
ffffe48d`45e4dea0 fffff802`642fa0f8 : 00000000`00000000 ffff36b4`d7ae09c0 00000000`00000001 ffffa989`3acce920 : msrpc!RpcBindingBind+0x2d
ffffe48d`45e4ded0 fffff802`642f9f05 : ffffe48d`45e4dff0 fffff802`00000040 00000000`00000000 00000000`00000000 : fwpkclnt!FwppRpcBindingBind+0x1c
ffffe48d`45e4df00 fffff802`642f9e26 : ffffe48d`45e4dff0 00000000`00000000 ffffffff`ffffffff fffff802`61589421 : fwpkclnt!FwppSessionCreate+0xb9
ffffe48d`45e4df70 fffff802`731d1338 : 00000000`c0000001 ffffe48d`45e517a1 00000000`00000000 00000000`00000000 : fwpkclnt!FwpmEngineOpen0+0x56
ffffe48d`45e4dfb0 fffff802`731d11b8 : fffff802`731d3520 00000000`00000000 00000000`00000000 ffffa989`2e8e28f0 : apegw!OpenEngine+0x4c [c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c # 616]
ffffe48d`45e4e060 fffff802`731d1428 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffa989`383c9000 : apegw!InitWfp+0x28 [c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c # 313]
ffffe48d`45e4e090 fffff802`731d1809 : 00000000`00000000 fffff802`6143e34c 00000000`00000000 ffffe48d`45e4e159 : apegw!RuleEngineStart+0x10 [c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c # 29]
ffffe48d`45e4e0c0 fffff802`614cb875 : ffffa989`30172bd0 fffff802`618c2677 ffffe48d`45e517a1 00000000`00000002 : apegw!WfpIRPDispatch+0x149 [c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c # 180]
ffffe48d`45e51700 fffff802`618c2c70 : ffffa989`30172bd0 ffffe48d`45e517a1 ffffa989`30172bd0 ffffa989`382210f0 : nt!IofCallDriver+0x55
ffffe48d`45e51740 fffff802`618c123c : 00000000`00000000 00000000`0022e024 ffffe48d`45e51b60 ffffa989`30172bd0 : nt!IopSynchronousServiceTail+0x1d0
ffffe48d`45e517f0 fffff802`618bf516 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x72c
ffffe48d`45e51a00 fffff802`6163d1e8 : 00000000`00000544 000000c8`12ffdcd8 000000c8`12ffdcd0 00000000`00000008 : nt!NtDeviceIoControlFile+0x56
ffffe48d`45e51a70 00007ffe`4e96eee4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
000000c8`12ffe448 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`4e96eee4
FAULTING_SOURCE_LINE: c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c
FAULTING_SOURCE_FILE: c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c
FAULTING_SOURCE_LINE_NUMBER: 180
SYMBOL_NAME: apegw!WfpIRPDispatch+149
MODULE_NAME: apegw
IMAGE_NAME: apegw.sys
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 149
FAILURE_BUCKET_ID: 0x7f_8_STACK_USAGE_apegw!WfpIRPDispatch
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {286d046a-caea-634c-9c2e-ffb90d719cec}
Followup: MachineOwner
---------
Here is the sample code which can reproduce this issue on the laptop with the problem. By the way, if I comment the code in file firewall.c which locate in test_driver from line 176 to line 184, issue disappear.
sample code: https://1drv.ms/u/s!AoZBPdtrfQp1hAMIkW0MgVcq7sVJ?e=AWklwy
Related
An Mbed code is throwing the crash dump below and I wish to find the line corresponding to the given PC. I'm on Windows though, so the simple "addr2line" is not available. I tried addr2line with Ubuntu shell on Windows, but it gives ??:?
What is the best tool on Windows 10 to perform address-to-line resolution from ARM ELF?
++ MbedOS Fault Handler ++
FaultType: HardFault
Context:
R0: 0
R1: 2000A0C8
R2: 1
R3: 14
R4: 20007854
R5: 2000A0
R6: 68
R7: 0
R8: 0
R9: 0
R10: 0
R11: 0
R12: 29FC1
SP : 2000A8B8
LR : 2C007
PC : 2000A0C8
xPSR : 0
PSP : 2000A898
MSP : 2003FFC0
CPUID: 410FC241
HFSR : 40000000
MMFSR: 0
BFSR : 0
UFSR : 2
DFSR : 0
AFSR : 0
Mode : Thread
Priv : Privileged
Stack: PSP
-- MbedOS Fault Handler --
I have a serious problem with a windows file system KMDF driver. the problem occurred after Windows 10 ver 1903 update (may latest update).
the driver was running smoothly before the update at any giving windows 10 versions.
When the driver start running the system CARSH (Blue Screen) with "WDF_VIOLATION" Error.
I opened the system dump file with the "Visual Studio windbg" tool, and i found this Error log:
WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 0000000000000005, A framework object handle of the incorrect type was passed to
a framework object method.
Arg2: 0000000000000000, The handle value passed in.
Arg3: 0000000000001023, Reserved.
Arg4: ffffd808fc533e00, Reserved.
Debugging Details:
------------------
KEY_VALUES_STRING: 1
Key : Analysis.CPU.Sec
Value: 7
Key : Analysis.Elapsed.Sec
Value: 23
Key : Analysis.Memory.CommitPeak.Mb
Value: 72
PROCESSES_ANALYSIS: 1
SERVICE_ANALYSIS: 1
STACKHASH_ANALYSIS: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 401
BUILD_VERSION_STRING: 18362.1.amd64fre.19h1_release.190318-1202
SYSTEM_MANUFACTURER: LENOVO
SYSTEM_PRODUCT_NAME: 20DCA020IV
SYSTEM_SKU: LENOVO_MT_20DC_BU_Think_FM_ThinkPad E450
SYSTEM_VERSION: ThinkPad E450
BIOS_VENDOR: LENOVO
BIOS_VERSION: J5ET63WW (1.34 )
BIOS_DATE: 09/26/2018
BASEBOARD_MANUFACTURER: LENOVO
BASEBOARD_PRODUCT: 20DCA020IV
BASEBOARD_VERSION: Not Defined
DUMP_TYPE: 1
BUGCHECK_P1: 5
BUGCHECK_P2: 0
BUGCHECK_P3: 1023
BUGCHECK_P4: ffffd808fc533e00
BUGCHECK_STR: 0x10D_5
CPU_COUNT: 4
CPU_MHZ: 893
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3d
CPU_STEPPING: 4
CPU_MICROCODE: 6,3d,4,0 (F,M,S,R) SIG: 2B'00000000 (cache) 2B'00000000 (init)
ADDITIONAL_DEBUG_TEXT:
You can run '.symfix; .reload' to try to fix the symbol path and load symbols.
FAULTING_MODULE: fffff8007c800000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 5cf4fafd
BUGCHECK_STR: 0x10D_5
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre
LAST_CONTROL_TRANSFER: from fffff8007f58b828 to fffff8007c9bc810
STACK_TEXT:
ffff9b0c`b3d0ee98 fffff800`7f58b828 : 00000000`0000010d 00000000`00000005 00000000`00000000 00000000`00001023 : nt!KeBugCheckEx
ffff9b0c`b3d0eea0 fffff800`7f559e27 : 0000001e`571ef000 00000000`00000000 00000000`00000001 00000000`00000001 : Wdf01000+0x5b828
ffff9b0c`b3d0eee0 fffff800`885f2bfc : 00000000`00000000 ffff9e0e`04604380 ffff9e0d`fec5f8b0 ffff9b0c`b3d0f280 : Wdf01000+0x29e27
ffff9b0c`b3d0ef20 fffff800`885f34c6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Cyber20UNCProvider!CA_EstablishConnection+0x40 [c:\_dev\workspace\agent-supdriver\supdriver_x64\sentineluncprovider\commagent.c # 99]
ffff9b0c`b3d0f170 fffff800`7f31cd8a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Cyber20UNCProvider!CS_SUPMessage+0x66 [c:\_dev\workspace\agent-supdriver\supdriver_x64\sentineluncprovider\commservice.c # 502]
ffff9b0c`b3d0f630 fffff800`7f34bf18 : ffff9b0c`b3d0f740 00000000`00000001 ffff9e0e`02efaaa0 00000000`00000000 : FLTMGR!FltGetIoPriorityHintFromCallbackData+0x15a
ffff9b0c`b3d0f690 fffff800`7f34bfd6 : ffff9e0e`02efab70 0000001e`575ff210 00000000`00000000 00000000`00000000 : FLTMGR!FltRemoveOpenReparseEntry+0x418
ffff9b0c`b3d0f6f0 fffff800`7f313f4f : ffff9e0d`faf716b0 00000000`00000002 00000000`00000000 fffff800`7ce1da15 : FLTMGR!FltRemoveOpenReparseEntry+0x4d6
ffff9b0c`b3d0f760 fffff800`7c827da9 : ffff9e0e`02efaaa0 00000000`00000000 00000000`0008801b 00000000`00000001 : FLTMGR!FltDecodeParameters+0x11ef
ffff9b0c`b3d0f7c0 fffff800`7ce15dd5 : ffff9e0e`02efaaa0 00000000`00000000 00000000`00000000 ffff9e0e`04cccbf0 : nt!IofCallDriver+0x59
ffff9b0c`b3d0f800 fffff800`7ce1572a : 00000000`00000000 00000000`0008801b 00000000`00000000 ffff9b0c`b3d0fb40 : nt!NtDeviceIoControlFile+0xce5
ffff9b0c`b3d0f8a0 fffff800`7ce15146 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtDeviceIoControlFile+0x63a
ffff9b0c`b3d0f9e0 fffff800`7c9cde98 : 00000000`00000000 ffff9b0c`b3d0fb40 ffff9e0e`0404a330 fffff800`7ce2288d : nt!NtDeviceIoControlFile+0x56
ffff9b0c`b3d0fa50 00007ffe`e453c144 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!setjmpex+0x7af8
0000001e`575febe8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`e453c144
STACK_COMMAND: kb
FOLLOWUP_IP:
Cyber20UNCProvider!CA_EstablishConnection+40 [c:\_dev\workspace\agent-supdriver\supdriver_x64\sentineluncprovider\commagent.c # 99]
fffff800`885f2bfc 48833d4c45000000 cmp qword ptr [Cyber20UNCProvider!CA_agentFileObject (fffff800`885f7150)],0
FAULTING_SOURCE_LINE: c:\_dev\workspace\agent-supdriver\supdriver_x64\sentineluncprovider\commagent.c
FAULTING_SOURCE_FILE: c:\_dev\workspace\agent-supdriver\supdriver_x64\sentineluncprovider\commagent.c
FAULTING_SOURCE_LINE_NUMBER: 99
FAULTING_SOURCE_CODE:
95: NTSTATUS status;
96:
97: WdfWaitLockAcquire(CA_agentFileObjectLock, NULL);
98:
> 99: if (CA_agentFileObject != NULL)
100: {
101: LoggerLog(LOGGER_LS_WARN, L"CommAgent.c", L"CA_EstablishConnection", L"Communication with the Agent is already established");
102:
103: WdfWaitLockRelease(CA_agentFileObjectLock);
104:
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: Cyber20UNCProvider!CA_EstablishConnection+40
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Cyber20UNCProvider
IMAGE_NAME: Cyber20UNCProvider.sys
BUCKET_ID: WRONG_SYMBOLS
FAILURE_BUCKET_ID: WRONG_SYMBOLS
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:wrong_symbols
FAILURE_ID_HASH: {70b057e8-2462-896f-28e7-ac72d4d365f8}
Followup: MachineOwner
The windbg marking line 99 as the crashing command, i did checked it and i found that the line above 99 is causing the problem:
"WdfWaitLockAcquire(CA_agentFileObjectLock, NULL);"
THE CODE:
The problem occurred in this function at the third line
NTSTATUS CA_EstablishConnection()
{
UNICODE_STRING agentIrpBusName;
NTSTATUS status;
WdfWaitLockAcquire(CA_agentFileObjectLock, NULL);
if (CA_agentFileObject != NULL)
{
LoggerLog(LOGGER_LS_WARN, L"CommAgent.c", L"CA_EstablishConnection", L"Communication with the Agent is already established");
WdfWaitLockRelease(CA_agentFileObjectLock);
return STATUS_SUCCESS;
}
RtlUnicodeStringInit(
&agentIrpBusName,
AS_IRPBUS_SUP_AGENT_NAME
);
// Connect to the Agent.
status = IoGetDeviceObjectPointer(
&agentIrpBusName,
FILE_ALL_ACCESS,
&CA_agentFileObject,
&CA_agentDeviceObject
);
if (status != STATUS_SUCCESS)
{
wchar_t strBuff[256];
swprintf_s(strBuff, 256, L"Cannot connect to the Agent. Reason: 0x%x", status);
LoggerLog(LOGGER_LS_ERROR, L"CommAgent.c", L"CA_EstablishConnection", strBuff);
}
WdfWaitLockRelease(CA_agentFileObjectLock);
return status;
}
More notes about the problem
KMDF 1.29 is not released yet
Microsoft mention that there is no functional changes in the WDF
As i mention before the code had no bugs until this last Windows 10 update (the software is in production)
you past only partial dump output. you need open dump in windbg and run !analyze -v command. i sure that you get something like:
WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 0000000000000005, A framework object handle of the incorrect type was passed to
a framework object method.
Arg2: 0000000000000000, The handle value passed in.
Arg3: 0000000000001023, Reserved.
why i think so ? because view next line
00000000`0000010d 00000000`00000005 00000000`00000000 00000000`00001023 : nt!KeBugCheckEx
this mean that KeBugCheckEx(10d, 5, 0, 1023, *) is called
where 10d is WDF_VIOLATION, 5 is WDF_INVALID_HANDLE, 1023 is FX_TYPE_WAIT_LOCK. so
KeBugCheckEx(WDF_VIOLATION, WDF_INVALID_HANDLE, 0, FX_TYPE_WAIT_LOCK, *)
is called.
this mean that you pass invalid lock object handle (because WDF_INVALID_HANDLE, FX_TYPE_WAIT_LOCK) with 0 value to call WdfWaitLockAcquire.
you also must install pdb files (for Wdf01000.sys and ntoskrnl.exe) - in this case you will view FxVerifierBugCheckWorker call instead Wdf01000+0x5b828
so in call WdfWaitLockAcquire(CA_agentFileObjectLock, NULL);
CA_agentFileObjectLock == NULL, why is this - of course not visible from information which you post
I'm trying to track down issues with a 3thParty application. The path currently being investigated is to look into a Section object that get's created in each process: rpsPdf10.mutex.
If the name of the object is any indication for it's intended usage, I'm not sure why they choose a Section object and use it as a Mutex but that's likely largely irrelevant.
Using LiveKd I've issued following command's trying to get detailed info of the Section object
0: kd>!process 0 0 3thParty.exe
...
PROCESS fffffa800ea80060
SessionId: 0 Cid: 0a00 Peb: fffdf000 ParentCid: 014c
DirBase: 99349000 ObjectTable: fffff8a004448bf0 HandleCount: 338.
Image: 3thParty.exe
...
0: kd> !handle 0 7 fffffa800ea80060
...
08 fffff8a012e26710 Section rpsPdf10.mutex
...
0: kd> !object fffff8a012e26710
Object: fffff8a012e26710 Type: (fffffa800cd7cea0) Section
ObjectHeader: fffff8a012e266e0 (new version)
HandleCount: 38 PointerCount: 39
Directory Object: fffff8a00a980080 Name: rpsPdf10.mutex
0: kd> dt nt!_FILE_OBJECT fffff8a012e26710
+0x000 Type : 0n256
+0x002 Size : 0n0
+0x008 DeviceObject : 0x000000000008dfb0 _DEVICE_OBJECT
+0x010 Vpb : 0xfffffa80c0000001 _VPB
+0x018 FsContext : (null)
+0x020 FsContext2 : 0xfffffa8000000034 Void
+0x028 SectionObjectPointer : 0xfffff8a0102d7820 _SECTION_OBJECT_POINTERS
+0x030 PrivateCacheMap : 0x0000000000001000 Void
+0x038 FinalStatus : 0n73728
+0x040 RelatedFileObject : 0x63536153030a040c _FILE_OBJECT
+0x048 LockOperation : 0x74 't'
+0x049 DeletePending : 0 ''
+0x04a ReadAccess : 0x65 'e'
+0x04b WriteAccess : 0 ''
+0x04c DeleteAccess : 0x73 's'
+0x04d SharedRead : 0 ''
+0x04e SharedWrite : 0x74 't'
The string 't' 'e' 's' 't' in the output definitely sticks out so
either I'm following a wrong path -> tx to Blabb, this is certain. It's not a fileobject but the question remains how to find out more information about the Section object. It's still curious and/or a rather unfortunate coincidence that following the section and control area pointers I derived from the fileobject info do seem correct?!
or there's something wrong with the Section object
or ... ?
tldr;
Following the _SECTION_OBJECT_POINTERS of the _FILE_OBJECT structure above, I arrive at a
NumberOfMappedViews of 0x26 (= HandleCount: 38)
NumberOfUserReferences of 0x27 (= PointerCount: 39)
so for the moment I assume the path I've followed is correct.
0: kd> dt nt!_SECTION_OBJECT_POINTERS 0xfffff8a0102d7820
+0x000 DataSectionObject : 0xfffffa800fbed900 Void
+0x008 SharedCacheMap : 0x0008000000000001 Void
+0x010 ImageSectionObject : 0x0000000000000001 Void
0: kd> dt nt!_CONTROL_AREA 0xfffffa800fbed900
+0x000 Segment : 0xfffff8a0102d7820 _SEGMENT
+0x008 DereferenceList : _LIST_ENTRY [ 0x0000000000000000 - 0x0000000000000000 ]
+0x018 NumberOfSectionReferences : 1
+0x020 NumberOfPfnReferences : 0
+0x028 NumberOfMappedViews : 0x26
+0x030 NumberOfUserReferences : 0x27
Edit
The object header looks like this
0: kd> dt nt!_OBJECT_HEADER fffff8a012e266e0
+0x000 PointerCount : 0n39
+0x008 HandleCount : 0n38
+0x008 NextToFree : 0x00000000`00000026 Void
+0x010 Lock : _EX_PUSH_LOCK
+0x018 TypeIndex : 0x21 '!'
+0x019 TraceFlags : 0 ''
+0x01a InfoMask : 0xa ''
+0x01b Flags : 0 ''
+0x020 ObjectCreateInfo : 0xfffffa80`0e505140 _OBJECT_CREATE_INFORMATION
+0x020 QuotaBlockCharged : 0xfffffa80`0e505140 Void
+0x028 SecurityDescriptor : 0xfffff8a0`1ba076a8 Void
+0x030 Body : _QUAD
Edit 2
following #blabb's answer adjusting for architecture
0: kd> ? #$proc
Evaluate expression: -6047068061600 = fffffa80`0ea80060
0: kd> dx (char *)#$proc->ImageFileName
(char *)#$proc->ImageFileName : 0xfffffa800ea80340 : [Type: char *] : "3thParty.exe"
0: kd> !handle 0 0 #$proc section
...
0474: Object: fffff8a012e26710 GrantedAccess: 000f0007
...
0: kd> !object fffff8a012e26710
Object: fffff8a012e26710 Type: (fffffa800cd7cea0) Section
ObjectHeader: fffff8a012e266e0 (new version)
HandleCount: 38 PointerCount: 39
Directory Object: fffff8a00a980080 Name: rpsPdf10.mutex
0: kd> ?? (unsigned long) (#FIELD_OFFSET(nt!_OBJECT_HEADER, Body))
unsigned long 0x30
0: kd> dt nt!_object_header 0xfffff8a012e26710-0x30
+0x000 PointerCount : 0n39
+0x008 HandleCount : 0n38
+0x008 NextToFree : 0x00000000`00000026 Void
+0x010 Lock : _EX_PUSH_LOCK
+0x018 TypeIndex : 0x21 '!'
+0x019 TraceFlags : 0 ''
+0x01a InfoMask : 0xa ''
+0x01b Flags : 0 ''
+0x020 ObjectCreateInfo : 0xfffffa80`0e505140 _OBJECT_CREATE_INFORMATION
+0x020 QuotaBlockCharged : 0xfffffa80`0e505140 Void
+0x028 SecurityDescriptor : 0xfffff8a0`1ba076a8 Void
+0x030 Body : _QUAD
0: kd> x nt!ObTypeIndexTable
fffff800`01a70c00 nt!ObTypeIndexTable = <no type information>
0: kd> dt -r1 nt!_SECTION_OBJECT 0xfffff8a012e26710
+0x000 StartingVa : 0x00000022`00000100 Void
+0x008 EndingVa : 0x00000000`0008dfb0 Void
+0x010 Parent : 0xfffffa80`c0000001 Void
+0x018 LeftChild : (null)
+0x020 RightChild : 0xfffffa80`00000034 Void
+0x028 Segment : 0xfffff8a0`102d7820 _SEGMENT_OBJECT
+0x000 BaseAddress : 0xfffffa80`0fbed900 Void
+0x008 TotalNumberOfPtes : 1
+0x010 SizeOfSegment : _LARGE_INTEGER 0x1
+0x018 NonExtendedPtes : 0x1000
+0x01c ImageCommitment : 0
+0x020 ControlArea : (null)
+0x028 Subsection : (null)
+0x030 MmSectionFlags : 0xfffffa80`10987b10 _MMSECTION_FLAGS
+0x038 MmSubSectionFlags : 0x00000000`03400000 _MMSUBSECTION_FLAGS
0: kd> dc 0xfffff8a012e26710-0x30-0x50
fffff8a0`12e26690 030c0408 f4636553 0e1a02e0 fffffa80 ....Sec.........
fffff8a0`12e266a0 00000048 000000b8 0000001c fffffa80 H...............
fffff8a0`12e266b0 0e505140 fffffa80 00000000 00000000 #QP.............
fffff8a0`12e266c0 0a980080 fffff8a0 001c001c 00000000 ................
fffff8a0`12e266d0 10eb8770 fffff8a0 00000000 00000008 p...............
fffff8a0`12e266e0 00000027 00000000 00000026 00000000 '.......&.......
fffff8a0`12e266f0 00000000 00000000 000a0021 fffff8a0 ........!.......
fffff8a0`12e26700 0e505140 fffffa80 1ba076a8 fffff8a0 #QP......v......
0: kd> !pool 0xfffff8a012e26710-0x30-0x50 2
Pool page fffff8a012e26690 region is Paged pool
*fffff8a012e26690 size: c0 previous size: 80 (Allocated) *Sect (Protected)
Pooltag Sect : Section objects
This is a 32 bit machine running windows 7
Commands used are architecture agnostic but pointer arithmetic are arch dependent
Current process
kd> ? #$proc
Evaluate expression: -2061895528 = 8519f898
Process Name From EPROCESS->ImageFileName
kd> dx (char *)#$proc->ImageFileName
(char *)#$proc->ImageFileName : 0xffffffff8519fa04 : "windbg.exe" [Type: char *]
lets Search For Some Section Handles in this process
the TypeName is CaseSensitive
kd> !handle 0 3 #$proc Section
Searching for handles of type Section
PROCESS 8519f898 SessionId: 1 Cid: 0138 Peb: 7ffd8000 ParentCid: 0d04
DirBase: 7e257560 ObjectTable: b91a3520 HandleCount: 254.
Image: windbg.exe
Handle table at b91a3520 with 254 entries in use
00c0: Object: 9a10bc58 GrantedAccess: 00000004 Entry: 9945b180
Object: 9a10bc58 Type: (84eb6040) Section
ObjectHeader: 9a10bc40 (new version)
HandleCount: 6 PointerCount: 6
!handle 0 3 flag dumps object specific information which can be reverified using !object {object address}
kd> !object 9a10bc58
Object: 9a10bc58 Type: (84eb6040) Section
ObjectHeader: 9a10bc40 (new version)
HandleCount: 6 PointerCount: 6
each object has an objectheader in 32 bit it is 18 bytes prior to object address that is sizeof(nt!_OBJECT_HEADER- sizeof(obheader->Body)) body is embedded in HEADER as the last member and is variable sized
kd> ?? (unsigned long ) (#FIELD_OFFSET(nt!_OBJECT_HEADER , Body))
unsigned long 0x18
_OBJECT_HEADER is as follows (though sizes haven't changed there are differences between new version header and old version header)
kd> dt nt!_object_header 9a10bc58-0x18
+0x000 PointerCount : 0n6
+0x004 HandleCount : 0n6
+0x004 NextToFree : 0x00000006 Void
+0x008 Lock : _EX_PUSH_LOCK
+0x00c TypeIndex : 0x21 '!'
+0x00d TraceFlags : 0 ''
+0x00e InfoMask : 0x8 ''
+0x00f Flags : 0 ''
+0x010 ObjectCreateInfo : 0x82f7aa00 _OBJECT_CREATE_INFORMATION
+0x010 QuotaBlockCharged : 0x82f7aa00 Void
+0x014 SecurityDescriptor : (null)
+0x018 Body : _QUAD
the old version header had _OBJECT_TYPE directly in the header
the new version is an index into an array
here the type index is 0x21
the array of Type is at
kd> x nt!ObTypeIndexTable
82f88580 nt!ObTypeIndexTable = <no type information>
you can write a script like this to dump all the types
function log(instr)
{
host.diagnostics.debugLog(instr + "\n");
}
function exec (cmdstr)
{
return host.namespace.Debugger.Utility.Control.ExecuteCommand(cmdstr);
}
function dumptypeindex()
{
var cpob = host.createPointerObject
var titab = exec("x nt!ObTypeIndexTable").First().substr(0,8)
var obtype = cpob(host.parseInt64(titab , 16),"nt","_OBJECT_TYPE **")
var i = 2
while(obtype[i] !=0 )
{
log("index = "+i+"\t"+ host.memory.readWideString(obtype[i].Name.Buffer))
i++
}
}
executing this script would yield the types as follows
kd> .scriptload c:\wdscr\dumptypeindex.js
JavaScript script successfully loaded from 'c:\dumptypeindex.js'
kd> dx #$scriptContents.dumptypeindex()
index = 2 Type
index = 3 Directory
index = 4 SymbolicLink
index = 5 Token
index = 6 Job
index = 7 Process
index = 8 Thread
index = 9 UserApcReserve
index = 10 IoCompletionReserve
index = 11 DebugObject
index = 12 Event
index = 13 EventPair
index = 14 Mutant
index = 15 Callback
index = 16 Semaphore
index = 17 Timer
index = 18 Profile
index = 19 KeyedEvent
index = 20 WindowStation
index = 21 Desktop
index = 22 TpWorkerFactory
index = 23 Adapter
index = 24 Controller
index = 25 Device
index = 26 Driver
index = 27 IoCompletion
index = 28 File
index = 29 TmTm
index = 30 TmTxȂ扏楄
index = 31 TmRm
index = 32 TmEn
index = 33 Section
index = 34 Session
index = 35 Key
index = 36 ALPC Port
index = 37 PowerRequest
index = 38 WmiGuid
index = 39 EtwRegistration
index = 40 EtwConsumer
index = 41 FilterConnectionPort
index = 42 FilterCommunicationPort
index = 43 PcwObject
notice 0x21 = 0n33 = Section
given that we have a Section
we can dump the Section Object
kd> dt -r1 nt!_SECTION_OBJECT 9a10bc58
+0x000 StartingVa : 0x90f87b44 Void
+0x004 EndingVa : 0x82efb58a Void
+0x008 Parent : 0xc0802000 Void
+0x00c LeftChild : (null)
+0x010 RightChild : 0xc0c0a280 Void
+0x014 Segment : 0x995ed8d8 _SEGMENT_OBJECT
+0x000 BaseAddress : 0x86b65740 Void
+0x004 TotalNumberOfPtes : 0xdf
+0x008 SizeOfSegment : _LARGE_INTEGER 0x000000df`00080000
+0x010 NonExtendedPtes : 0xdf000
+0x014 ImageCommitment : 0
+0x018 ControlArea : (null)
+0x01c Subsection : (null)
+0x020 MmSectionFlags : 0x869f52a8 _MMSECTION_FLAGS
+0x024 MmSubSectionFlags : 0x02ea0000 _MMSUBSECTION_FLAGS
an object is preceded by object header which is preceded by the pool_header
kd> dc 9a10bc58-0x18-0x18
9a10bc28 060b0204 f4636553 00000720 00000070 ....Sec. ...p...
9a10bc38 00000000 00000000 00000006 00000006 ................
9a10bc48 00000000 00080021 82f7aa00 00000000 ....!...........
9a10bc58 90f87b44 82efb58a c0802000 00000000 D{....... ......
9a10bc68 c0c0a280 995ed8d8 000df000 00000000 ......^.........
9a10bc78 00012000 00000004 0670020b 6666744e . ........p.Ntff
9a10bc88 00f00702 00000a48 0000c0fe 00020000 ....H...........
9a10bc98 00000000 00000002 00000000 00000000 ................
notice the Sec tag Sect is used by SectionObjects
d> !pool 9a10bc58-0x18-0x18 2
Pool page 9a10bc28 region is Paged pool
*9a10bc28 size: 58 previous size: 20 (Allocated) *Sect (Protected)
Pooltag Sect : Section objects
I wanna get some memory dump of a specific process.
I've found each windows process contain VadRoot in a EPROCESS.
I used windbg to get some information of this structure...
kd> dt nt!_MMVAD fffffa801b7011d0
+0x000 u1 : <unnamed-tag>
+0x008 LeftChild : (null)
+0x010 RightChild : (null)
+0x018 StartingVpn : 0x7fefe440
+0x020 EndingVpn : 0x7fefe4b0
+0x028 u : <unnamed-tag>
+0x030 PushLock : _EX_PUSH_LOCK
+0x038 u5 : <unnamed-tag>
+0x040 u2 : <unnamed-tag>
+0x048 Subsection : 0xfffffa80`19f62640 _SUBSECTION
+0x048 MappedSubsection : 0xfffffa80`19f62640 _MSUBSECTION
+0x050 FirstPrototypePte : 0xfffff8a0`00b3ac28 _MMPTE
+0x058 LastContiguousPte : 0xffffffff`fffffffc _MMPTE
+0x060 ViewLinks : _LIST_ENTRY [ 0xfffffa80`1b7a38c0 - 0xfffffa80`1aa6d6a0 ]
+0x070 VadsProcess : 0xfffffa80`1b7e8941 _EPROCESS
Its Win7 64bit.
I guess StartingVpn: 0x7fefe440 has contain the memory contents of this block.
But is that a virtual address? or physical address? i don't know
what it stands for...
Thanks.
locate process
lkd> !process 0 0 explorer.exe
PROCESS 8a1908d0 ...... Image: explorer.exe
set process context
lkd> .process /p /r 8a1908d0
view reqd module
lkd> lm m explorer
start end module name
01000000 010ff000 Explorer (deferred)
get the vadroot for a virtual address in the current process context
lkd> !vad explorer 1
VAD # 8a120ed0
Start VPN 1000 End VPN 10fe Control Area 8a81ab80
FirstProtoPte e23e9048 LastPte fffffffc Commit Charge 3 (3.)
Secured.Flink 0 Blink 0 Banked/Extend 0
File Offset 0
ImageMap ViewShare EXECUTE_WRITECOPY
ReadOnly
ControlArea # 8a81ab80
Segment e23e9008 Flink 00000000 Blink 00000000
Section Ref 1 Pfn Ref 4d Mapped Views 1
User Ref 2 WaitForDel 0 Flush Count 0
File Object 8ab28240 ModWriteCount 0 System Views 0
Flags (90000a0) Image File HadUserReference Accessed
\WINDOWS\explorer.exe
Segment # e23e9008
ControlArea 8a81ab80 BasedAddress 01000000
Total Ptes ff
WriteUserRef 0 SizeOfSegment ff000
Committed 0 PTE Template 8a81ac3000000420
Based Addr 1000000 Image Base 0
Image Commit 2 Image Info e23e9840
ProtoPtes e23e9048
Reload command: .reload explorer.exe=01000000,ff000
dump all the vads for a current process context
lkd> !vad 8a120ed0 0
VAD level start end commit
8a03b1d8 ( 3) e50 e51 0 Mapped READONLY Pagefile-backed section
8a6fe240 ( 4) e60 e6f 0 Mapped READWRITE Pagefile-backed section
................................
89c86600 ( 5) ff0 ff0 1 Private READWRITE
8a120ed0 ( 0) 1000 10fe 3 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\explorer.exe
.................................
8a87bb18 ( 7) 26d0 2733 0 Mapped READWRITE \Documents and Settings\Admin\Local Settings\History\History.IE5\index.dat
8a74b420 ( 0) 3e1c0 3ec52 10 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\ieframe.dll
8abfa398 ( 1) 7ffde 7ffde 1 Private READWRITE
Total VADs: 1231, average level: 5, maximum depth: 4294967295
VAD is short for virtual address descriptor and VPN is short for virtual page number. So it's a virtual address, not a physical address.
It needs to be translated to a physical address using PTEs (page table entry).
Given a user mode address I found with a user mode debugging session:
0:032> !address
[...]
+ 7ff`fffdc000 7ff`fffde000 0`00002000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE TEB [~1; 13ec.10fc]
0:032> dd 7ff`fffde000 L8
000007ff`fffde000 00000000 00000000 00240000 00000000
000007ff`fffde010 0022b000 00000000 00000000 00000000
I can do this in a kernel debugging session using LiveKd (SysInternals):
0: kd> !process 0 0 explorer.exe
PROCESS fffffa8012ce5b10
SessionId: 1 Cid: 13ec Peb: 7fffffd6000 ParentCid: 13c0
DirBase: 3029e8000 ObjectTable: fffff8a006139d60 HandleCount: 1078.
Image: explorer.exe
0: kd> .process /p /r fffffa8012ce5b10
Implicit process is now fffffa80`12ce5b10
Loading User Symbols
[...]
0: kd> !vtop 0 7fffffde000
Amd64VtoP: Virt 000007ff`fffde000, pagedir 00000003`029e8000
Amd64VtoP: PML4E 00000003`029e8078
Amd64VtoP: PDPE 00000003`00ebcff8
Amd64VtoP: PDE 00000003`0203dff8
Amd64VtoP: PTE 00000003`01ebeef0
Amd64VtoP: Mapped phys 00000002`ff44f000
Virtual address 7fffffde000 translates to physical address 2ff44f000.
0: kd> dd /p 2ff44f000 L8
00000002`ff44f000 00000000 00000000 00240000 00000000
00000002`ff44f010 0022b000 00000000 00000000 00000000
Note how the content of the virtual address (dd) is identical to the physical address (dd /p).
I am writing an extension for Windbg, and at a particular point I need to get the permissions for a memory offset, much like how !address addr would provide in Windbg. I have had a look at the available functions of the Debugger Engine API here at:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff551059%28v=vs.85%29.aspx
However I have failed to find such a function that would return the section/permissions information against a memory offset. Basically I would like to get what section the address lies in, data section, text section etc, what permissions it has and so on.
The closest sounding function I have found is GetOffsetInformation in the IDebugDataSpaces4 interface. However as per the documentation, it doesn't provide anything from what I am looking for:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff548055(v=vs.85).aspx
I could always run the !address command and have its output parsed, but I was looking for a cleaner way where I could get this information directly, by using the API.
Am I missing something? Is there a documented/undocumented way I could achieve this with?
Doesnt QueryVirtual Work ?
#include <engextcpp.hpp>
class EXT_CLASS : public ExtExtension
{
public:
EXT_COMMAND_METHOD(getoffinfo);
};
EXT_DECLARE_GLOBALS();
EXT_COMMAND( getoffinfo, "", "{;e,d=0;getoffinfo;simulates !address <address>}" )
{
ULONG64 Offset = GetUnnamedArgU64(0);
if (Offset == 0)
{
Out( "usage !getoffinfo <address>\n");
}
else
{
MEMORY_BASIC_INFORMATION64 meminfo;
memset(&meminfo,0,sizeof(MEMORY_BASIC_INFORMATION64 ));
m_Data2->QueryVirtual(Offset,&meminfo);
Out("Allocation Base : %x\n",meminfo.AllocationBase);
Out("Base Address : %x\n",meminfo.BaseAddress);
Out("End Address : %x\n",meminfo.AllocationBase + meminfo.RegionSize);
Out("RegionSize : %x\n",meminfo.RegionSize);
Out("Type : %x\n",meminfo.Type);
Out("State : %x\n",meminfo.State);
}
}
result as follows
0:000> !address windbg
Usage: Image
Allocation Base: 01000000
Base Address: 01000000
End Address: 01001000
Region Size: 00001000
Type: 01000000 MEM_IMAGE
State: 00001000 MEM_COMMIT
Protect: 00000002 PAGE_READONLY
More info: lmv m windbg
More info: !lmi windbg
More info: ln 0x1000000
0:000> .load getoffinfo
0:000> !getoffinfo
usage !getoffinfo <address>
0:000> !getoffinfo windbg
Allocation Base : 1000000
Base Address : 1000000
End Address : 1001000
RegionSize : 1000
Type : 1000000
State : 1000