Crash Analyzing-- 0xC0000005: Access violation writing location 0x00000010

本文通过一个具体的案例,详细分析了在使用CriticalSection时遇到的崩溃及异常情况。探讨了不当使用CriticalSection可能导致的问题,并提供了复现问题的代码示例。

Sometime, when you use CriticalSection, if you encountered crashing or exception?

Call Stack looks like th following via Windbg:

0:000> k
ChildEBP RetAddr 
0012fe88 7c90104b ntdll!RtlpWaitForCriticalSection+0x8c
0012fe90 004135fb ntdll!RtlEnterCriticalSection+0x46
0012ff68 004119f6 CriticalTest!wmain+0x2b []
0012ffb8 0041183d CriticalTest!__tmainCRTStartup+0x1a6 []
0012ffc0 7c816fd7 CriticalTest!wmainCRTStartup+0xd []
0012fff0 00000000 kernel32!BaseProcessStart+0x23

0:000> .exr -1
ExceptionAddress: 7c918fea (ntdll!RtlpWaitForCriticalSection+0x0000008c)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 00000010
Attempt to write to address 00000010

0:000> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*************************************************************************
***                                                                   ***
***                                                                   ***
***    Your debugger is not using the correct symbols                 ***
***                                                                   ***
***    In order for this command to work properly, your symbol path   ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: kernel32!pNlsUserInfo                         ***
***                                                                   ***
*************************************************************************
*************************************************************************
***                                                                   ***
***                                                                   ***
***    Your debugger is not using the correct symbols                 ***
***                                                                   ***
***    In order for this command to work properly, your symbol path   ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: kernel32!pNlsUserInfo                         ***
***                                                                   ***
*************************************************************************

FAULTING_IP:
ntdll!RtlpWaitForCriticalSection+8c
7c918fea ff4010          inc     dword ptr [eax+10h]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 7c918fea (ntdll!RtlpWaitForCriticalSection+0x0000008c)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 00000010
Attempt to write to address 00000010

DEFAULT_BUCKET_ID:  APPLICATION_FAULT

PROCESS_NAME:  CriticalTest.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

WRITE_ADDRESS:  00000010

BUGCHECK_STR:  ACCESS_VIOLATION

CRITICAL_SECTION:  00417160 -- (!cs -s 00417160)

LAST_CONTROL_TRANSFER:  from 7c90104b to 7c918fea

STACK_TEXT: 
0012fe88 7c90104b 00417160 004135fb 00417160 ntdll!RtlpWaitForCriticalSection+0x8c
0012fe90 004135fb 00417160 7c911970 02bbf55c ntdll!RtlEnterCriticalSection+0x46
0012ff68 004119f6 00000001 003a3090 003a3148 CriticalTest!wmain+0x2b []
0012ffb8 0041183d 0012fff0 7c816fd7 7c911970 CriticalTest!__tmainCRTStartup+0x1a6 [f:/sp/vctools/crt_bld/self_x86/crt/src/crtexe.c @ 594]
0012ffc0 7c816fd7 7c911970 02bbf55c 7ffdb000 CriticalTest!wmainCRTStartup+0xd [f:/sp/vctools/crt_bld/self_x86/crt/src/crtexe.c @ 414]
0012fff0 00000000 0041107d 00000000 00000000 kernel32!BaseProcessStart+0x23


STACK_COMMAND:  ~0s; .ecxr ; kb

FAULTING_THREAD:  00001668

FOLLOWUP_IP:
CriticalTest!wmain+2b []
004135fb 3bf4            cmp     esi,esp

FAULTING_SOURCE_CODE: 
    25: {
    26:     // Initialize the critical section one time only.
    27:     //InitializeCriticalSection(&CriticalSection);
    28:
>   29:     EnterCriticalSection(&CriticalSection);
    30:
    31:  //CreateThread(NULL, 0, ThreadProc, NULL, 0, NULL);
    32:  
    33:  LeaveCriticalSection(&CriticalSection);
    34:


SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  CriticalTest!wmain+2b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: CriticalTest

IMAGE_NAME:  CriticalTest.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  47eca49a

BUCKET_ID:  ACCESS_VIOLATION_CriticalTest!wmain+2b

FAILURE_BUCKET_ID:  CriticalTest.exe!wmain_c0000005_APPLICATION_FAULT

Followup: MachineOwner

using commands !critsec,!cs,!locks, but get nothing about locks.

0:000> kb
ChildEBP RetAddr  Args to Child             
0012fe88 7c90104b 00417160 004135fb 00417160 ntdll!RtlpWaitForCriticalSection+0x8c
0012fe90 004135fb 00417160 7c911970 02bbf55c ntdll!RtlEnterCriticalSection+0x46
0012ff68 004119f6 00000001 003a3090 003a3148 CriticalTest!wmain+0x2b []
0012ffb8 0041183d 0012fff0 7c816fd7 7c911970 CriticalTest!__tmainCRTStartup+0x1a6 [f:/sp/vctools/crt_bld/self_x86/crt/src/crtexe.c @ 594]
0012ffc0 7c816fd7 7c911970 02bbf55c 7ffdb000 CriticalTest!wmainCRTStartup+0xd [f:/sp/vctools/crt_bld/self_x86/crt/src/crtexe.c @ 414]
0012fff0 00000000 0041107d 00000000 00000000 kernel32!BaseProcessStart+0x23
0:000> !critsec 00417160

CritSec at 00417160 could not be read
Perhaps the critical section was a global variable in a dll that was unloaded?

0:000> !cs -s 00417160
Cannot read DebugInfo adddress at 0x00417160. Possible causes:
 - The critical section is not initialized, deleted or corrupted
 - The critical section was a global variable in a DLL that was unloaded
 - The memory is paged out
Cannot read structure field value at 0x00417164, error 0
Cannot determine if the critical section is locked or not.
-----------------------------------------
Critical section   = 0x00417160 (CriticalTest!CriticalSection+0x0)
DebugInfo          = 0x00000016
Cannot read structure field value at 0x00000018, error 0

0:000> !locks
NTSDEXTS: Unable to read memory at ntdll!RtlCriticalSectionList
0:000> !locks -o
Looking for orphaned critical sections
NTSDEXTS: Unable to read memory at ntdll!RtlCriticalSectionList

A critical section becomes undefined in a couple of ways:
1. No call to InitializeCriticalSection(...)
2. Multiple call to InitializeCriticalSection(...) with no call to DeleteCriticalSection(...) in between the re-init.
3. Call to DeleteCriticalSection(...) but still referencing the critical section.
4. Thread calls EnterCriticalSection(...) and exits with no call to LeaveCriticalSection(...). Second thread calls EnterCriticalSection(...).

So it is caused by a undefined or deleted Critical Section.

You can repro it via the following codes:
// Not initilize the Critical section.
// Global variable
CRITICAL_SECTION CriticalSection;

int _tmain(int argc, _TCHAR* argv[])
{
    //InitializeCriticalSection(&CriticalSection);

    EnterCriticalSection(&CriticalSection);

  
    LeaveCriticalSection(&CriticalSection);


    DeleteCriticalSection(&CriticalSection);

    return 0;
}


or access a deleted Critical section.

// Global variable
CRITICAL_SECTION CriticalSection;

DWORD WINAPI ThreadProc( LPVOID lpParameter )
{
 //InitializeCriticalSection(&CriticalSection);

    // Request ownership of the critical section.
    EnterCriticalSection(&CriticalSection);

    // Release ownership of the critical section.
    LeaveCriticalSection(&CriticalSection);

 DeleteCriticalSection(&CriticalSection);

 return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
    // Initialize the critical section one time only.
    InitializeCriticalSection(&CriticalSection);

 CreateThread(NULL, 0, ThreadProc, NULL, 0, NULL);
  
 Sleep(3000);

 EnterCriticalSection(&CriticalSection);

 LeaveCriticalSection(&CriticalSection);

 DeleteCriticalSection(&CriticalSection);

 return 0;
}

 

请解释该broute表:Bridge table: broute Bridge chain: BROUTING, entries: 22, policy: ACCEPT -p 0x893a -j ieee1905 --1905-data 00000004 --1905-target DROP -p 0x893a -d 00:0A:EB:13:09:69 -j DROP -d 02:0A:EB:13:09:69 -j DROP -d 02:0A:EB:13:09:6A -j DROP -p 0x88cc -d 01:80:C2:00:00:0E -j DROP -d 01:80:C2:00:00:13 -j DROP -j QoSTypeRule0 -j QoSTypeRule1 -j QoSTypeRule3 -j QoSTypeRule4 -j QoSTypeRule5 -j QoSTypeRule6 -j QoSTypeRule7 -j QoSTypeRule8 -j QoSTypeRule9 -j QoSTypeRule10 -j QoSTypeRule11 -j QoSTypeRule12 -j QoSTypeRule13 -j QoSTypeRule14 -j QoSTypeRule15 -j QoSTypeRule2 Bridge chain: QoSTypeRule0, entries: 0, policy: RETURN Bridge chain: QoSVlanRule0, entries: 0, policy: RETURN Bridge chain: QoSTypeRule0Remark, entries: 2, policy: RETURN -j mark --mark-or 0x2 --mark-target CONTINUE -j mark --mark-or 0x10 --mark-target ACCEPT Bridge chain: QoSTypeRule1, entries: 1, policy: RETURN -s C2:CF:39:62:E8:57 -j QoSTypeRule1Remark Bridge chain: QoSVlanRule1, entries: 0, policy: RETURN Bridge chain: QoSTypeRule1Remark, entries: 2, policy: RETURN -j mark --mark-or 0x1002 --mark-target CONTINUE -j mark --mark-or 0x20 --mark-target ACCEPT Bridge chain: QoSTypeRule2, entries: 1, policy: RETURN -j QoSTypeRule2Remark Bridge chain: QoSVlanRule2, entries: 0, policy: RETURN Bridge chain: QoSTypeRule2Remark, entries: 2, policy: RETURN -j mark --mark-or 0x2002 --mark-target CONTINUE -j mark --mark-or 0x30 --mark-target ACCEPT Bridge chain: QoSTypeRule3, entries: 1, policy: RETURN -s E0:D3:62:46:55:6B -j QoSTypeRule3Remark Bridge chain: QoSVlanRule3, entries: 0, policy: RETURN Bridge chain: QoSTypeRule3Remark, entries: 2, policy: RETURN -j mark --mark-or 0x3002 --mark-target CONTINUE -j mark --mark-or 0x40 --mark-target ACCEPT
最新发布
09-23
<think> Hmm, the user is asking about the detailed structure and rules within a specific ebtables broute table configuration. From the output provided, this seems to be a complex network setup likely from a home router or enterprise gateway device. First, I recognize that the BROUTING chain has 22 entries with various packet handling rules - some dropping specific protocols like 0x893a (likely HSML/1905.1) and LLDP frames, while others jump to QoS-related chains. Interesting how it mixes both security drops (blocking certain multicast MACs) and QoS marking in the same table. The QoS chains follow a clear pattern: each "QoSTypeRuleX" chain references a corresponding "Remark" chain that applies packet marks using bitwise OR operations. For instance, QoSTypeRule3 first applies mark 0x3002 then 0x40. This layered marking suggests sophisticated traffic classification - probably for prioritizing different device types or services. Noticing the MAC-specific rules too: QoSTypeRule1 and QoSTypeRule3 activate only for specific source MAC addresses (C2:CF:39:62:E8:57 and E0:D3:62:46:55:6B). That's likely targeting individual devices for special QoS treatment. The empty QoSVlanRule chains indicate VLAN handling might be configured elsewhere. What's clever is how the design separates matching (in QoSTypeRule chains) from marking actions (in Remark chains). This modular approach would make rule maintenance easier. The CONTINUE target after initial marking allows multiple rules to cumulatively modify the packet mark - a smart use of ebtables' capabilities. The user seems to be analyzing network equipment configurations, possibly for troubleshooting or optimization. Their persistence in digging into broute details suggests they're either a network admin or an advanced user. Since they've asked about rule behavior before, they're probably trying to understand how packet flows get processed holistically. </think> 以下是对 `ebtables -t broute -L` 输出结果的完整解析,重点关注表结构和规则含义: ### BROUTE 表结构解析 1. **主链 BROUTING** - **策略**:`policy: ACCEPT`(默认允许通过) - **规则明细**: - `-p 0x893a -j ieee1905 --1905-data 00000004 --1905-target DROP` → 丢弃 IEEE 1905.1 协议(0x893a)且数据为 `00000004` 的包 - `-d 02:0A:EB:13:09:69 -j DROP` → 丢弃目标 MAC 为 `02:0A:EB:13:09:69`(保留组播地址)的包 - `-j QoSTypeRuleX` → 跳转到对应的 QoS 子链(共 16 条,用于分层处理 QoS 标记) 2. **QoS 子链结构**(以 QoSTypeRule3 为例) ```markdown Bridge chain: QoSTypeRule3, entries: 1, policy: RETURN -s E0:D3:62:46:55:6B -j QoSTypeRule3Remark # 仅匹配特定源MAC时跳转 Bridge chain: QoSTypeRule3Remark, entries: 2, policy: RETURN -j mark --mark-or 0x3002 --mark-target CONTINUE # 添加标记位 0x3002 -j mark --mark-or 0x40 --mark-target ACCEPT # 添加标记位 0x40 后通过 ``` - **分层处理逻辑**: 1. 主链通过 `-j` 将包分发到子链 2. 子链通过 MAC 匹配(如 `-s E0:D3:62:46:55:6B`)过滤设备 3. `mark --mark-or` 对包进行位或标记(多级叠加) 4. `CONTINUE` 使包继续匹配后续规则 5. `ACCEPT` 终止当前链处理 3. **关键设计特点** - **安全隔离**:丢弃 HSML/1905.1协议(`0x893a`)及特定组播地址(如 `01:80:C2:00:00:0E`) - **模块化 QoS**: - 通过 16 条独立子链实现分类流量标记 - 标记值设计(如 `0x3002` + `0x40`)支持位掩码组合 - **链式处理**: `RETURN` 策略确保未匹配时返回父链,避免规则冲突 ### 核心功能总结 - **核心作用**:控制桥接流量的路由决策(BROUTING)和 QoS 分级(QoSTypeRuleX) - **标记原理**:`--mark-or` 对包标记进行位或运算(如 `0x3002 | 0x40 = 0x3042`),用于后续路由策略识别 - **设备绑定**:子链通过源 MAC(如 `E0:D3:62:46:55:6B`)将规则绑定到特定设备 > 此配置常见于智能网关设备,实现多设备差异化 QoS 和协议过滤。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值