97久久精品人人澡人人爽,精品国产日韩久久亚洲,久久综合伊人77777

jans2002 — Wed, 14 Oct 2009 00:37:00 GMT

可以通过反汇�~�来知道接口函数的参敎ͼ��使用W32DSM来分析，也可以直接��用VC来分析，��是�ȝ��(ch��)一炏V�?nbsp;
现在使用W32DSM来具体说明：(x��)
1。先打开需要分析的DLL�Q�然后通过菜单功能-》出口来扑ֈ�需要分析的函数�Q�双��d��可以�?ji��n)�?nbsp;
它可以直接定位到该函数�?nbsp;
2。看准该函数的入口，一般函数是以以下代码作为入口点的�?nbsp;
push     ebp
mov         ebp,     esp
...
3。然后往下找到该函数的出口，一般函数出口有以下语句�?nbsp;
...
ret         xxxx;//其中xxxx��是函数差数的所有的字节敎ͼ��?的倍数�Q�xxxx除以4得到的结�?nbsp;
��是参数的个数�?nbsp;
其中参数存放的地方：(x��)
ebp+08                     //�W�一个参�?nbsp;
ebp+0C                     //�W�二个参�?nbsp;
ebp+10                     //�W�三个参�?nbsp;
ebp+14                     //�W�四个参�?nbsp;
ebp+18                     //�W�五个参�?nbsp;
ebp+1C                     //�W�六个参�?nbsp;
。。。�?nbsp;
-------------------------------------------
�q�有一�U�经常看到的调用方式�Q?nbsp;
sub     esp,xxxx                     //开头部�?nbsp;
//函数的内�?nbsp;
。。�?nbsp;
//函数的内�?nbsp;
add     esp,xxxx
ret                                                         //�l�尾部分
其中xxxx/4的结果也是参数的个数�?nbsp;
-------------------------------------------------
�q�有一�U�调用方式：(x��)
有于该函数比较简单，没有参数的压栈过�E�，
里面�?nbsp;
esp+04��是�W�一个参�?nbsp;
esp+08��是�W�二个参�?nbsp;
。。�?nbsp;
esp+xx��是�W�xx/4个参�?nbsp;
你说看到的xx的最大数除以4后的�l�果�Q�就是该函数所传递的参数的个数�?nbsp;
----------------------------------------------
到现在位�|�，你应该能很清楚的看到�?ji��n)传递的参数的个数。至于传递的是些什么内容，�q�需要进一步的分析�?nbsp;
最方便的办法就是先扑ֈ�是什么��Y件在调用此函敎ͼ�然后通过调试的技术，扑ֈ�该函数被调用的地斏V��一般都是PUSH指��o(h��)
来实现参数的传递的。这时可以看一下具体是什么东西被压入堆栈�?ji��n)，一般来��_(d��)��如果参数是整敎ͼ�一看就可以知道�?ji��n)�?nbsp;
如果是字�W�串的话也是比较��单的�Q�只要到那个地址上面�ȝ��一下就可以�?ji��n)�?nbsp;
如果传递的�l�构的话�Q�没有很方便的办法解冻I��是��L��该汇�~�就可以�?ji��n)。对于以上的分析�Q�本人只其到�?ji��n)抛砖引玉�?nbsp;
希望对大家有点用处�?

jans2002 2009-10-14 08:37 发表评论

(�?一个小技巧：(x��)SFP Overwrite�Q�以c语言为实例）(j��)

jans2002 — Tue, 29 Sep 2009 01:09:00 GMT

SFP Overwrite
I'd like a share a little trick I figured out today. I'm sure it has been done before and probably many times but its new to me so I'll describe it here. I asked myself if anything cool could be achieved by overwriting the Saved Frame Pointer instead of the Return Address. I'm not sure what sort of security-related attacks could be leveraged by doing this, but I did find that its possible to affect the program flow in the calling function. This is just another trick to change the flow of execution and even works on a non-executable stack.
The vulnerable program source code
The attack program source code
EBP and Local Variables
The extended base pointer is a register used by the CPU as base for the current stack frame. As we discussed earlier, the EBP for the function that called the current one is stored in the current function's Saved Frame Pointer. The EBP points to this SFP; in this way, there is a chain of saved EBPs for each stack frame. Check out the EIP Redirection page for more details about this. The location of the current stack frame's SFP is stored in the Extended Base Pointer.
Keeping track of the chain of the program's stack frames is not the only purpose of the EBP/SFPs. As the name implies, the Extended Base Pointer register holds an address that is used as the "base" of the current stack frame (this address is the frame's SFP). The code in the current function references local variables using EBP as a base. For example, the C code for setting a variable equal to 3 is myVar = 3;. This might be assembled into something like: MOV SS:[EBP - 4], 0x03. This means that the local variable myVar is referred to as "the address on the stack stored in EBP, minus 4 bytes" by the assembled code. Another variable in the same function called myVar2 might be located at SS:[EBP - 8]. We can see that if an attacker could change the value of EBP, they could also change where the code thinks local variables are.
Using SFP to Modify EBP

Imagine that there is function called FunctionA that is not vulnerable to any sort of buffer overflow. Inside it is a local integer variable that is used by the function later on. Before the variable is used, another function called FunctionB is called. This one happens to be vulnerable to a buffer overflow. Our goal is to trick FunctionA into using a variable that we define instead of the one that it declared.
We wait until the execution reaches FunctionB and we are able to input our malicious buffer. At the beginning we'll have the value of the fake variable that FunctionA will be tricked into using. From there, we pad the buffer with junk until the saved frame pointer is reached. Now we push the address on the stack that is directly below our fake variable. The reason we do this is that FunctionA references its real variable as SS:[ebp - 4]. Therefore, our injected EBP must be 4 bytes beyond our fake variable. By setting it up in this way, if we can manage to get that address into the Extended Base Pointer while FunctionA is executing; our fake variable will be referenced instead of the real one. We are not overwriting the value in the real variable. Instead, we are changing FunctionA's perception of its location to an address inside the buffer that we control.
The Target
Now its time to put our attack into a context. At the top of the source code, you'll notice the vulnerable test() function. All it does is declare a 5 byte buffer and fail to protect it while its being filled with user input. The main() function declares a local integer variable (4 bytes) and feeds the decimal value 3 into it. Main() then calls the test() function which asks the user for input but doesn't do anything with it. After test() returns, a loop is entered. The loop keeping looping as long as the integer c is greater than zero. Each time it repeats, the value of c is decreased by one and "Later" is displayed on the screen. Overall, this thing prints that word c times. Because the value of this integer was set to 3 earlier, this means that "Later" is printed 3 times by this loop.
We will trick this program into thinking that a variable we create using the vulnerable buffer is actually c. By filling this fake variable with the decimal value 500,000,001, we'll make this loop run and print "Later" 500 million and one times instead of the expected three.
Buiding the Attack
As before, we'll be writing a program in C that will feed a malicious string into the input of the vulnerable program. Because our ultimate goal is to overwrite the test() function's SFP, we'll need to pad the string appropriately to get there. The first 4 bytes of the attack string will be the value of our fake variable that main() will eventually use in its loop. These bytes need to equal the goal of 500,000,001 so we'll feed "\x01\x65\xCD\x1D" first. The next four do not matter in this case, but take note that they will become main()'s fake SFP. From here use OllyDbg to find the distance between this fake main() SFP and test()'s SFP. If you are unsure where the test() function's SFP is, you can always step the program until inside test() and check the EBP register. You'll find that the buffer begins at 0x0027FF00 and the test() function's SFP is located at 0x0027FF18. After converting to decimal and subtracting the 8 bytes we already used up so far, it means we'll need to add 16 bytes of padding to reach test()'s SFP.

Next we'll actually overwrite the SFP. Have a look at the main() function and you'll find that the loop references the variable c as SS:[EBP - 4]. This means that if we want it to reference that 4 byte value at the beginning of the buffer instead, we need main()'s EBP to point to the address 4 bytes beyond the beginning of our attack buffer. We've already pointed out that any value we can sneak into test()'s SFP will end up in the EBP when main() returns. So we end the attack string with the following 3 bytes: "\x04\xFF\x27". The value is chosen because 0x0027FF04 - 4 is the address of our fake variable. Writing all four bytes is, again, not necessary because gets() automatically sticks a null byte at the end of the string inputted.
Final Overview
By crafting the above buffer and ensuring that the last 3 bytes overwrite test()'s SFP, we directly control EBP when test() returns back to main(). Because main() uses EBP to reference an important variable c and we control EBP; we make main() think that c is actually where our old overwritten buffer began. The data is still there because there was no reason for the program to erase/modify it. Because c is referenced as SS:[EBP - 4] in main(), we need that overwritten Stack Frame Pointer to point to the address four bytes below the fake variable location on the stack. When main uses our fake EBP to reference variable c is it will subtract 4 from it and find our fake variable value. This was filled in with the decimal value of 500,000,001. Main() runs the loop to print "Later" a number of times determined by c. So by doing all of this trickery we can make the program display "Later" 500,000,001 times instead of 3.

jans2002 2009-09-29 09:09 发表评论

jans2002 — Fri, 14 Aug 2009 09:59:00 GMT

AspectC++ Add-In for Microsoft® Visual C++®
http://www.pure-systems.com/fileadmin/downloads/acaddin/Aspectc-AddIn-Setup-010101.exe
我用的是VS2003环境
调试目标�Q�C:\Program Files\pure-systems\AspectC++ Add-In\bin\CPPAddin.dll
工具�Q�用OD调试�Q�IDA+Hex-rays分析
重点集中在以下几个地址
0x10008e60 弹许可文件询问的对话�?br />0x10017a20 解析xml格式的许可文�?br />0x10017730 貌似许可��(g��)查的地方
�q�个�?br />0x10008e60的由Hex-ray分析出来的伪代码,

代码:

char __usercall sub_1000E860(int a1)
{
  int ST14_4_0; // ST14_4@0
  int v2; // ST10_4@1
  const CHAR *v3; // eax@3
  const CHAR *v4; // eax@10
  int v6; // eax@2
  char v7; // bl@2
  char v8; // al@9
  int v9; // [sp+Ch] [bp-9Ch]@1
  signed int v10; // [sp+A4h] [bp-4h]@1
  char v11; // [sp+10h] [bp-98h]@1
  char v12; // [sp+48h] [bp-60h]@2
  char v13; // [sp+2Ch] [bp-7Ch]@2
  LPCSTR lpText; // [sp+14h] [bp-94h]@3
  unsigned int v15; // [sp+28h] [bp-80h]@3
  char v16; // [sp+64h] [bp-44h]@15

  BYTE3(v9) = 0;
  sub_10016AA0();
  v10 = 0;
  std__basic_string_char_std__char_traits_char__std__allocator_char____basic_string_char_std__char_traits_char__std__allocator_char__(&v11);
  LOBYTE(v10) = 1;
  v2 = a1;
  while ( 1 )
  {
    sub_100169B0(16, (int)&v12);
    LOBYTE(v10) = 2;
    v6 = std__operator_(&v13, v6, "\\etc\\licence");
    LOBYTE(v10) = 3;
    v7 = sub_10017A20((int)&unk_10024460, v6, (int)&v11) == 0;
    LOBYTE(v10) = 2;
    std__basic_string_char_std__char_traits_char__std__allocator_char_____basic_string_char_std__char_traits_char__std__allocator_char__(&v13);
    LOBYTE(v10) = 1;
    std__basic_string_char_std__char_traits_char__std__allocator_char_____basic_string_char_std__char_traits_char__std__allocator_char__(&v12);
    if ( !v7 )
      break;
    std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(
      &v11,
      "\nThe add-in will not work without a valid licence.\n\nInstall the licence file now?",
      v2);
    v3 = lpText;
    if ( v15 < 0x10 )
      v3 = (const CHAR *)&lpText;
    if ( MessageBoxA(0, v3, "AspectC++ Add-In for Visual Studio .NET", 0x24u) != 6 )
      break;
    if ( !sub_1000E690() )
    {
      MessageBoxA(0, "Installation of licence file failed.", "AspectC++ Add-In", 0x40u);
      break;
    }
  }
  if ( byte_10024465 )
  {
    sub_10017730((int)&unk_10024460, 16, (int)&v11);
    if ( v8 && (unsigned __int8)sub_10017520(&v11) != 1 )
    {
      BYTE3(v9) = 1;
    }
    else
    {
      std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(
        &v11,
        "\nThe add-in will not work.",
        ST14_4_0);
      v4 = lpText;
      if ( v15 < 0x10 )
        v4 = (const CHAR *)&lpText;
      MessageBoxA(0, v4, "AspectC++ Add-In", 0x40u);
    }
  }
  LOBYTE(v10) = 0;
  std__basic_string_char_std__char_traits_char__std__allocator_char_____basic_string_char_std__char_traits_char__std__allocator_char__(&v11);
  v10 = -1;
  sub_10016910((int)&v16);
  return BYTE3(v9);
}

基本上可以得出默认是分析
C:\Program Files\pure-systems\AspectC++ Add-In\etc\licence 许可文�g
分析�q�程应该�?x10017a20�?

代码:

char __thiscall sub_10017A20(int this, int a2, int a3)
{
  int v3; // ebp@1
  int v4; // esi@1
  int v5; // eax@2
  int v6; // eax@4
  int v7; // edi@5
  char result; // al@8
  int v9; // ecx@1
  int v10; // eax@5
  int v11; // eax@6
  int v12; // ST04_4@6
  char v13; // bl@6
  char v14; // [sp+Ch] [bp-28h]@6
  signed int v15; // [sp+30h] [bp-4h]@6

  v3 = a3;
  v4 = this;
  v9 = this + 96;
  *(_DWORD *)v9 = 0;
  *(_DWORD *)(v9 + 4) = 0;
  *(_DWORD *)(v9 + 8) = 0;
  *(_DWORD *)(v9 + 12) = 0;
  *(_BYTE *)(v4 + 5) = 0;
  std__basic_string_char_std__char_traits_char__std__allocator_char____operator_(v3, "Loading licence file failed.");
  if ( *(_DWORD *)(a2 + 24) < 0x10u )
    v5 = a2 + 4;
  else
    v5 = *(_DWORD *)(a2 + 4);
  v6 = xmlParseFile(v5);
  *(_DWORD *)v4 = v6;
  if ( v6
    && (v10 = xmlDocGetRootElement(v6), v7 = v10, v10)
    && (v11 = std__basic_string_char_std__char_traits_char__std__allocator_char____basic_string_char_std__char_traits_char__std__allocator_char__(
                &v14,
                "licence"), v12 = *(_DWORD *)(v7 + 8), v15 = 0, v13 = std__operator__(v11, v12), v15 = -1, std__basic_string_char_std__char_traits_char__std__allocator_char_____basic_string_char_std__char_traits_char__std__allocator_char__(&v14), v13)
    && sub_10017930(v7) )
  {
    *(_BYTE *)(v4 + 5) = 1;
    sub_10017730(v4, v3, v3);
    result = 1;
  }
  else
  {
    result = 0;
  }
  return result;
}

�q�是0x10017730的过�E?

代码:

void __userpurge sub_10017730(int this, int ebp0, int a2)
{
  int ST18_4_0; // ST18_4@0
  int ST1C_4_0; // ST1C_4@0
  int v5; // esi@1
  signed int v6; // eax@4
  int v7; // ST18_4@6
  int v8; // eax@20
  int v9; // eax@4
  int v10; // ST1C_4@12
  int v11; // ST1C_4@18
  int  r; // [sp+60h] [bp+0h]@1
  int v13; // [sp+50h] [bp-10h]@1
  signed int v14; // [sp+5Ch] [bp-4h]@3
  char v15; // [sp+34h] [bp-2Ch]@4
  char v16; // [sp+18h] [bp-48h]@4
  int v17; // [sp+1Ch] [bp-44h]@12
  unsigned int v18; // [sp+30h] [bp-30h]@20
  int v19; // [sp+2Ch] [bp-34h]@22

  v5 = this;
  v13 =  r ^ dword_100242D0;
  std__basic_string_char_std__char_traits_char__std__allocator_char____operator_(a2, "Invalid licence file found.");
  if ( *(_BYTE *)(v5 + 5) && !*(_BYTE *)(v5 + 4) )
  {
    sub_10017B20((int)&a2, ebp0);
    v14 = 0;
    if ( !sub_1001A050((int)&a2) )
    {
LABEL_23:
      v14 = -1;
      sub_1001A060(&a2);
      goto LABEL_24;
    }
    v9 = std__operator_(&v15, v5 + 12, v5 + 40);
    LOBYTE(v14) = 1;
    std__operator_(&v16, v9, v5 + 68);
    LOBYTE(v14) = 3;
    std__basic_string_char_std__char_traits_char__std__allocator_char_____basic_string_char_std__char_traits_char__std__allocator_char__(&v15);
    v6 = *(_DWORD *)(v5 + 8);
    if ( v6 || !*(_DWORD *)(v5 + 96) )
    {
      if ( v6 == 1 && *(_DWORD *)(v5 + 96) && *(_DWORD *)(v5 + 100) && *(_DWORD *)(v5 + 104) && *(_DWORD *)(v5 + 108) )
      {
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v16, "evaluation", ST18_4_0);
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(
          &v17,
          *(_DWORD *)(v5 + 96),
          ST1C_4_0);
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(
          &v17,
          *(_DWORD *)(v5 + 100),
          v10);
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(
          &v17,
          *(_DWORD *)(v5 + 104),
          ST1C_4_0);
        v7 = *(_DWORD *)(v5 + 108);
      }
      else
      {
        if ( v6 != 2
          || !*(_DWORD *)(v5 + 96)
          || !*(_DWORD *)(v5 + 100)
          || !*(_DWORD *)(v5 + 104)
          || !*(_DWORD *)(v5 + 108) )
          goto LABEL_20;
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v16, "user", ST18_4_0);
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(
          &v17,
          *(_DWORD *)(v5 + 96),
          ST1C_4_0);
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(
          &v17,
          *(_DWORD *)(v5 + 100),
          v11);
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(
          &v17,
          *(_DWORD *)(v5 + 104),
          ST1C_4_0);
        v7 = *(_DWORD *)(v5 + 108);
      }
    }
    else
    {
      std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v16, "beta", ST18_4_0);
      v7 = *(_DWORD *)(v5 + 96);
    }
    std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v17, v7, ST1C_4_0);
LABEL_20:
    v8 = v17;
    if ( v18 < 0x10 )
      v8 = (int)&v17;
    *(_BYTE *)(v5 + 4) = sub_10019E30(v5 + 112, v8, v19, (int)&a2);
    LOBYTE(v14) = 0;
    std__basic_string_char_std__char_traits_char__std__allocator_char_____basic_string_char_std__char_traits_char__std__allocator_char__(&v16);
    goto LABEL_23;
  }
LABEL_24:
  sub_1001A7B0( r ^ v13, ebp0);
}

昨天我自��p��试的时候也犯了(ji��n)一个错误，��是调试CppAddin.dll很痛苦，��费不少旉��和分散很多的�_�֊��Q�中间老是受到Va_X.dll的干扎ͼ�而且msdev.exe在CppAddin没加载时没法直接下断点，必须得在OD中设�|�一个新模块加蝲的断点（选项->调试选项->事�g->中断于新模块�Q?�q�样下来�Q�每�ơ调试失败后重启的过�E�很是�O长，��费�?ji��n)不��时��_(d��)��发帖子的求助的时候，我�ؓ(f��)�?ji��n)大大们�l�我能方便的解决问题�Q�尽量把非技术问题都试验�?ji��n)一下，以免大大们被�q�些问题��C��?ji��n)，一怒之下不�l�我��我�?ji��n)。但是这样一来，也�ؓ(f��)我自��p��军_��发现问题加快�?ji��n)速度�?br />�ȝ��一下：(x��)
1.解决问题要东方不亮，西方亮，不要��自��q��力消耗在�q�离问题本��n的地�?br /> 2.坚持��是胜利�Q�哪怕是菜鸟�Q�不懂多��汇�~�（看代码还得靠伟大、光荣、正��的F5�Q�，也能取得成�W
下面写写分析�q�程�Q?br />其实昨天已经扑ֈ��?ji��n)关键的�q�程�Q�那��是0x10017a20�Q�这里面��是分析xml格式的许可文�?br />�q�里面有两个调用�Q�sub_10017930()�?sub_10017730()
大概可以看得出来�Q�sub_10017930参与�?ji��n)xml格式的许可数据的解析�q�程�Q�它调用成功之后�Q�才调用10017730�Ҏ(gu��)��据进行验证，要分析许可数据格式，必须研究10017930

代码:

char __stdcall sub_10017930(int a1)
{
  int v1; // ebp@1
  int v2; // esi@1
  int v3; // esi@3
  char result; // al@7
  int v5; // eax@1
  int v6; // eax@2
  char v7; // bl@2
  char v8; // [sp+Ch] [bp-28h]@2
  signed int v9; // [sp+30h] [bp-4h]@2

  v1 = a1;
  v5 = xmlGetProp(a1, "version");
  v2 = v5;
  if ( v5
    && (v6 = std__basic_string_char_std__char_traits_char__std__allocator_char____basic_string_char_std__char_traits_char__std__allocator_char__(
               &v8,
               L"1"), v9 = 0, v7 = std__operator__(v6, v2), v9 = -1, std__basic_string_char_std__char_traits_char__std__allocator_char_____basic_string_char_std__char_traits_char__std__allocator_char__(&v8), v7) )
  {
    v3 = *(_DWORD *)(v1 + 12);
    result = (unsigned __int8)sub_10016D60(*(_DWORD *)(v1 + 12))
          && (unsigned __int8)sub_10016E70(v3)
          && (unsigned __int8)sub_10017570(v3)
          && (unsigned __int8)sub_100172C0(v3);
  }
  else
  {
    result = 0;
  }
  return result;
}

在这里面取了(ji��n)xml的一个属性值version,�q�且�q�有四个都不能失败的�q�程:
10016d60 取product 元素
10016e70 取creation 元素
10017570 取type元素
100172c0 取signature元素
��Z��(ji��n)熟�?zh��n)�libxml,我特意编写了(ji��n)一�D�典型libxml用法,�q�分析了(ji��n)其反向工�E�后的代码，

代码:

 xmlDocPtr doc = NULL;
  xmlNodePtr cur = NULL;
  string filename("test.xml");
  doc = xmlParseFile(filename.c_str());
  cur = xmlDocGetRootElement(doc);
  if (xmlStrcmp(cur->name, BAD_CAST "licence")) 
  {

    fprintf(stderr,"document of the wrong type, root node != mail"); 

    xmlFreeDoc(doc); 

    /*return -1; */

  } 
  cur = cur->xmlChildrenNode;
  xmlNodePtr propNodePtr = cur;
  while(cur != NULL) 
  {   
    //¨¨?3??¨²¦Ì??D¦Ì??¨²¨¨Y
    if ((!xmlStrcmp(cur->name, (const xmlChar *)"product"))) 
    {
        
          string name;
          string version;
          xmlChar* szAttr = xmlGetProp(cur,BAD_CAST "name"); 

          name=(char*)szAttr;

          szAttr=xmlGetProp(cur,BAD_CAST "version");

          version=(const char *)szAttr;
          cout<<"Name:"< Version:"<next;
  }


    

  xmlFreeDoc(doc);
  /*return 0;*/

得出的结论是�Q�凡是属性值的获取�Q�都�?x��)调用xmlGetProp�Q�而子元素的获取则是通过直接讉K��内存�l�构或者类似c++的函数访问，不会(x��)看到函数名称的引用，�Ҏ(gu��)��q�一�l�论和具体的调试�Q�大致推出来licence文�g的结构如�?

代码:

xml version="1.0" encoding="UTF-8"?>
<licence version="1">
<product name="aspect" version="1.0"/>
<product name="pointcut" version="1.0" />
<product name="advice"  version="1.0" />
<product name="slice"  version="1.0" />
<creation date="2009-8-13"/>
<type name="user">
<data code="xxxx" name="jans2002" email="jans2002@gmail.com" regnr="ccccc"/>
type>
<signature sign="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" />
licence>

有了(ji��n)�q�个licence文�g�Q�把它放�?br />C:\Program Files\pure-systems\AspectC++ Add-In\etc\目录�?br />一切问题就变得��单了(ji��n),��利执行完了(ji��n)0x10017930�Q�一路杀�?x10017730

代码:

int __thiscall sub_10017730(int this, int a2)
{
  int v2; // esi@1
  signed int v3; // eax@4
  int v4; // ST14_4@6
  int v5; // eax@20
  int v7; // eax@4
  int  r; // [sp+4Ch] [bp+0h]@1
  int v9; // [sp+3Ch] [bp-10h]@1
  signed int v10; // [sp+48h] [bp-4h]@3
  char v11; // [sp+20h] [bp-2Ch]@4
  char v12; // [sp+4h] [bp-48h]@4
  int v13; // [sp+8h] [bp-44h]@20
  unsigned int v14; // [sp+1Ch] [bp-30h]@20
  int v15; // [sp+18h] [bp-34h]@22

  v2 = this;
  v9 =  r ^ dword_100242D0;
  std__basic_string_char_std__char_traits_char__std__allocator_char____operator_(a2, "Invalid licence file found.");
  if ( *(_BYTE *)(v2 + 5) && !*(_BYTE *)(v2 + 4) )
  {
    sub_10017B20();
    v10 = 0;
    if ( !(unsigned __int8)sub_1001A050() )
    {
LABEL_23:
      v10 = -1;
      sub_1001A060();
      return sub_1001A7B0();
    }
    v7 = std__operator_(&v11, v2 + 12, v2 + 40);
    LOBYTE(v10) = 1;
    std__operator_(&v12, v7, v2 + 68);
    LOBYTE(v10) = 3;
    std__basic_string_char_std__char_traits_char__std__allocator_char_____basic_string_char_std__char_traits_char__std__allocator_char__(&v11);
    v3 = *(_DWORD *)(v2 + 8);
    if ( v3 || !*(_DWORD *)(v2 + 96) )
    {
      if ( v3 == 1 && *(_DWORD *)(v2 + 96) && *(_DWORD *)(v2 + 100) && *(_DWORD *)(v2 + 104) && *(_DWORD *)(v2 + 108) )
      {
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v12, "evaluation");
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v12, *(_DWORD *)(v2 + 96));
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v12, *(_DWORD *)(v2 + 100));
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v12, *(_DWORD *)(v2 + 104));
        v4 = *(_DWORD *)(v2 + 108);
      }
      else
      {
        if ( v3 != 2
          || !*(_DWORD *)(v2 + 96)
          || !*(_DWORD *)(v2 + 100)
          || !*(_DWORD *)(v2 + 104)
          || !*(_DWORD *)(v2 + 108) )
          goto LABEL_20;
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v12, "user");
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v12, *(_DWORD *)(v2 + 96));
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v12, *(_DWORD *)(v2 + 100));
        std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v12, *(_DWORD *)(v2 + 104));
        v4 = *(_DWORD *)(v2 + 108);
      }
    }
    else
    {
      std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v12, "beta");
      v4 = *(_DWORD *)(v2 + 96);
    }
    std__basic_string_char_std__char_traits_char__std__allocator_char____operator__(&v12, v4);
LABEL_20:
    v5 = v13;
    if ( v14 < 0x10 )
      v5 = (int)&v13;
    *(_BYTE *)(v2 + 4) = sub_10019E30(v2 + 112, v5, v15, (int)&a2);
    LOBYTE(v10) = 0;
    std__basic_string_char_std__char_traits_char__std__allocator_char_____basic_string_char_std__char_traits_char__std__allocator_char__(&v12);
    goto LABEL_23;
  }
  return sub_1001A7B0();
}

�׃��有了(ji��n)正确格式的licence�Q�前面执行的都很��利�Q�一直到�?ji��n)sub_10019E30,跟进��M��看，一切了(ji��n)然了(ji��n):

代码:

bool __thiscall sub_10019E30(int this, int a2, int a3, int a4)
{
  int v5; // esi@1
  int v6; // eax@1
  int v7; // eax@1
  char v8; // [sp+4h] [bp-10h]@1

  v5 = this;
  v6 = EVP_sha1();
  EVP_DigestInit(&v8, v6);
  EVP_DigestUpdate(&v8, a2, a3);
  v7 = sub_1001A030();
  return EVP_VerifyFinal(&v8, v5, *(_DWORD *)(v5 + 4096), v7) == 1;

前面一定都是加密验证的�Q�但是函数最后来�?ji��n)一�?

代码:

EVP_VerifyFinal(&v8, v5, *(_DWORD *)(v5 + 4096), v7) == 1;

嘿嘿�Q�看名字估计��是�q�个�?ji��n)，看看�q�个函数的返回��|��1表示成功�Q�其他表�C�失败，那就是只要让此函数永�q�返�?�Q�就大功告成�?ji��n)，该到汇编代码�?

代码:

004066F0  /$  83EC 10       sub     esp, 10                          ; ���(g��)查数字签名部�?
004066F3  |.  56            push    esi
004066F4  |.  8BF1          mov     esi, ecx
004066F6  |.  E8 81270000   call    
004066FB  |.  50            push    eax
004066FC  |.  8D4424 08     lea     eax, dword ptr [esp+8]
00406700  |.  50            push    eax
00406701  |.  E8 70270000   call    
00406706  |.  8B4C24 24     mov     ecx, dword ptr [esp+24]
0040670A  |.  8B5424 20     mov     edx, dword ptr [esp+20]
0040670E  |.  51            push    ecx
0040670F  |.  52            push    edx
00406710  |.  8D4424 14     lea     eax, dword ptr [esp+14]
00406714  |.  50            push    eax
00406715  |.  E8 56270000   call    
0040671A  |.  8B4C24 34     mov     ecx, dword ptr [esp+34]
0040671E  |.  83C4 14       add     esp, 14
00406721  |.  E8 2A100000   call    00407750
00406726  |.  8B8E 00100000 mov     ecx, dword ptr [esi+1000]
0040672C  |.  50            push    eax
0040672D  |.  51            push    ecx
0040672E  |.  8D5424 0C     lea     edx, dword ptr [esp+C]
00406732  |.  56            push    esi
00406733  |.  52            push    edx
00406734  |.  E8 49270000   call    
00406739  |.  83C4 10       add     esp, 10
0040673C  |.  48            dec     eax
0040673D  |.  F7D8          neg     eax
0040673F      1BC0          sbb     eax, eax
00406741      90            inc     eax
00406742      5E            pop     esi
00406743      83C4 10       add     esp, 10
00406746  \.  C2 0C00       retn    0C

一般来�Ԍ��函数�q�回值都�?x��)用EAX,不管三七二十一�?ji��n)，先吧EAX做了(ji��n)再说�Q�把上面那个黑体�?br />inc eax �Ҏ(gu��)��nop�Q�呵呵，nop是大家的最�?机器码是90�?�q�是改过的了(ji��n))
保存到文件�?br />大功告成哈！�Q?

�w��ؓ(f��)菜鸟�Q�能取得�q�样的结果，真是让�h兴奋�Q�谢谢各位阅读，�q�请各位高手不吝赐教�?br />下蝲安装�E�序�?qi��ng)破�?/a>

jans2002 2009-08-14 17:59 发表评论

jans2002 — Fri, 14 Aug 2009 09:51:00 GMT

在一个��用UNICODE的工�E�里使用log4cplus 1.0.3库，发现��L��发生链接错误。猜惛_��能是log4cplus需要在UNICODE下编译，��Z��Debug和Release两个复制�?ji��n)Unicode Debug/Release配置�Q�开始编译�?UniRelease很容易通过�?ji��n)编译，但是UniDebug却��L��发生链接错误�Q�但是函数肯定已�l�实��C��(ji��n)�Q�将链接错误发生的文件Appender.obj文�g打开�Q�然后比较编译器里报出的信息

一个是

?error@OnlyOnceErrorHandler@log4cplus@@UAEXABV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z
而链式器找不到的�W�号是：(x��)

?error@OnlyOnceErrorHandler@log4cplus@@UAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z
�q�两个符号都很晦涩，很难让�h搞明白什么意思，攄��一搜，�q�真有工具叫undname.exe�Q�在VC7.1里自带，
Undecoration of :- "?error@OnlyOnceErrorHandler@log4cplus@@UAEXABV?$basic_string
@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z"
is :- "public: virtual void __thiscall log4cplus::OnlyOnceErrorHandler::error(cl
ass std::basic_string,cla
ss std::allocator > const &)"
Undecoration of :- "?error@OnlyOnceErrorHandler@log4cplus@@UAEXABV?$basic_string
@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z"
is :- "public: virtual void __thiscall log4cplus::OnlyOnceErrorHandler::error(cl
ass std::basic_string,class std::allocatorar> > const &)"
一�Ҏ(gu��)��Q�就知道可能�q�是UNICODE的原因，仔细��(g��)查C++预处理符可��|�，发现好多都还是MCBS�Q�修改，重新�~�译�Q�问题解冟�?

jans2002 2009-08-14 17:51 发表评论

��单的makefile例子

jans2002 — Sun, 05 Apr 2009 01:35:00 GMT

NAME   =   loggingserver
all   :   $(NAME).exe
$(NAME).obj:   $(NAME).cxx
    cl   $(NAME).cxx   /G7   /MD   /Ox   /Ot   /W3   /c   /EHsc   /I "D:\log4cplus-1.0.3\include"
$(NAME).exe:   $(NAME).obj
    link   $(NAME).obj    /out:$(NAME).exe /LIBPATH:"D:\log4cplus-1.0.3\msvc6\Debug" /SUBSYSTEM:CONSOLE   /MACHINE:X86 log4cplusd.lib
clean:
    del *.obj
    del *.exe

jans2002 2009-04-05 09:35 发表评论

jans2002 — Fri, 20 Feb 2009 02:03:00 GMT

解开 Windows 下的临界��Z��的代码死�?/h3>

Matt Pietrek�?Russ Osterlund

本文假定�(zh��n)�熟�(zh��n)?Win32、C++ 和多�U�程处理�?

下蝲本文的代码：(x��)CriticalSections.exe (415KB)

摘要

临界区是一�U�防止多个线�E�同时执行一个特定代码节的机�Ӟ��q�一主题�q�没有引起太多关注，因而�h们未能对其深�ȝ��解。在需要跟�t�代码中的多�U�程处理的性能�Ӟ��?Windows 中��(f��)界区的深�ȝ��解非常有用�?本文深入研究临界区的原理�Q�以揭示在查找死锁和��认性能问题�q�程中的有用信息。它�q�包含一个便利的实用工具�E�序�Q�可以显�C�所有��(f��)界区�?qi��ng)其当前状态�?

在我们许多年的编�E�实践中�Q�对�?Win32�] 临界区没有受到非常多的“under the hood”关注而感到非常奇怪。当�?d��ng)��?zh��n)�可能了(ji��n)解有关��(f��)界区初始化与使用的基��知识�Q�但�(zh��n)�是否曾�l�花�Ҏ(gu��)��间来深入研究 WINNT.H 中所定义�?CRITICAL_SECTION �l�构呢？在这一�l�构中有一些非常有意义的好东西被长期忽略。我们将�Ҏ(gu��)��q�行补充�Q��ƈ向�?zh��n)�介绍一些很有意义的技巧，�q�些技巧对于跟�t�那些难以察觉的多线�E�处理错误非常有用。更重要的是�Q��用我们的 MyCriticalSections 实用工具�Q�可以明白如何对 CRITICAL_SECTION �q�行微小地扩展，以提供非常有用的�Ҏ(gu��)��，�q�些�Ҏ(gu��)��可用于调试和性能调整�Q�要下蝲完整代码�Q�参见本文顶部的链接�Q��?

老实��_(d��)��作者们�l�常忽略 CRITICAL_SECTION �l�构的部分原因在于它在以下两个主�?Win32 代码库中的实现有很大不同�Q�Microsoft�] Windows�] 95 �?Windows NT�]。�h们知道这两种代码库都已经发展出大量后�l�版本（其最新版本分别�ؓ(f��) Windows Me �?Windows XP�Q�，但没有必要在此处��其一一列出。关键在�?Windows XP 现在已经发展得非常完善，开发商可能很快��׃��(x��)停止�?Windows 95 �p�d��操作�pȝ��的支持。我们在本文中就是这么做的�?

诚然�Q�当今最受关注的�?Microsoft .NET Framework�Q�但是良好的旧式 Win32 �~�程不会(x��)很快消失。如果�?zh��n)�拥有采用了(ji��n)�?f��)界区的现�?Win32 代码�Q��?zh��n)�会(x��)发现我们的工具以�?qi��ng)对��(f��)界区的说明都非常有用。但是请注意�Q�我们只讨论 Windows NT �?qi��ng)其后�?hu��)版本�Q�而没有涉�?qi��ng)�?.NET 相关的�Q何内容，�q�一炚w��帔R��要�?

临界区：(x��)��q?

如果�(zh��n)�非常熟�(zh��n)��(f��)界区�Q��ƈ可以不假思烦(ch��)地进行应用，那就可以略过本节。否则，请向下阅读，以对�q�些内容�q�行快速回��。如果�?zh��n)�不熟�?zh��n)�这些基��内容�Q�则本节之后的内容就没有太大意义�?

临界区是一�U�轻量��机制�Q�在某一旉��内只允许一个线�E�执行某个给定代码段。通常在修改全局数据�Q�如集合�c�）(j��)时会(x��)使用临界区。事件、多用户�l�端执行�E�序和信号量也用于多�U�程同步�Q�但临界��Z��它们不同�Q�它�q�不��L��执行向内核模式的控制转换�Q�这一转换成本昂贵。稍后将�?x��)看刎ͼ�要获得一个未占用临界区，事实上只需要对内存做出很少的修改，光��度非常快。只有在��试获得已占用��(f��)界区�Ӟ��它才�?x��)蟩臛_��核模式。这一轻量�U�特性的�~�点在于临界区只能用于对同一�q�程内的�U�程�q�行同步�?

临界区由 WINNT.H 中所定义�?RTL_CRITICAL_SECTION �l�构表示。因为�?zh��n)��?C++ 代码通常声明一�?CRITICAL_SECTION �c�d��的变量，所以�?zh��n)�可能��?gu��)��q�不�?ji��n)解。研�I?WINBASE.H 后�?zh��n)�会(x��)发玎ͼ?x��)

typedef RTL_CRITICAL_SECTION CRITICAL_SECTION;

我们��在短时间内揭示 RTL_CRITICAL_SECTION �l�构的实质。此�Ӟ��重要问题在于 CRITICAL_SECTION�Q�也�U�C�� RTL_CRITICAL_SECTION�Q�只是一个拥有易讉K��字段的结构，�q�些字段可以�?KERNEL32 API 操作�?

在将临界��Z��递给 InitializeCriticalSection �Ӟ��或者更准确地说�Q�是在传递其地址�Ӟ��(j��)�Q��(f��)界区卛_��始存在。初始化之后�Q�代码即��(f��)界区传递给 EnterCriticalSection �?LeaveCriticalSection API。一个线�E�自 EnterCriticalSection 中返回后�Q�所有其他调�?EnterCriticalSection 的线�E�都��被��L��Q�直到第一个线�E�调�?LeaveCriticalSection 为止。最后，当不再需要该临界区时�Q�一�U�良好的�~�码�?f��n)惯是将其传递给 DeleteCriticalSection�?

在��(f��)界区未被使用的理��x(ch��ng)��况中�Q�对 EnterCriticalSection 的调用非常快速，因�ؓ(f��)它只是读取和修改用户模式内存?sh��)��的内存�(sh��)��置。否则（在后文将�?x��)遇��C��U�例外情况）(j��)�Q�阻止于临界区的�U�程有效地完成这一工作�Q�而不需要消耗额外的 CPU 周期。所��L��的线�E�以内核模式�{�待�Q�在该��(f��)界区的所有者将光��放之前，不能对这些线�E�进行调度。如果有多个�U�程被阻止于一个��(f��)界区中，当另一�U�程释放该��(f��)界区�Ӟ��只有一个线�E�获得该临界区�?

深入研究�Q�RTL_CRITICAL_SECTION �l�构

即��(zh��n)�已�l�在日常工作中��用过临界区，�(zh��n)�也非常可能�q�没有真正了(ji��n)解超出文档之外的内容。事实上存在着很多非常�Ҏ(gu��)��掌握的内宏V��例如，��Z��很少知道一个进�E�的临界区是保存?sh��)��一个链表中�Q��ƈ且可以对其进行枚举。实际上�Q�W(xu��)INDBG 支持 !locks 命��o(h��)�Q�这一命��o(h��)可以列出目标�q�程中的所有��(f��)界区。我们稍后将要谈到的实用工具也应用了(ji��n)临界��一鲜�ؓ(f��)人知的特征。�ؓ(f��)�?ji��n)真正理解这一实用工具如何工作�Q�有必要真正掌握临界区的内部�l�构。记着�q�一点，现在开始研�I?RTL_CRITICAL_SECTION �l�构。�ؓ(f��)方便赯��Q�将此结构列出如下：(x��)

struct RTL_CRITICAL_SECTION
{
    PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
    LONG LockCount;
    LONG RecursionCount;
    HANDLE OwningThread;
    HANDLE LockSemaphore;
    ULONG_PTR SpinCount;
};

以下各段�Ҏ(gu��)��个字�D�进行说明�?

DebugInfo 此字�D�包含一个指针，指向�pȝ��分配的伴随结构，该结构的�c�d��?RTL_CRITICAL_SECTION_DEBUG。这一�l�构中包含更多极有�h(hu��n)值的信息�Q�也定义�?WINNT.H 中。我们稍后将对其�q�行更深入地研究�?

LockCount �q�是临界��Z��最重要的一个字�D�c(di��n)��它被初始化为数�?-1�Q�此数值等于或大于 0 �Ӟ��表示此��(f��)界区被占用。当其不�{�于 -1 �Ӟ��OwningThread 字段�Q�此字段被错误地定义�?WINNT.H �?�?应当�?DWORD 而不�?HANDLE�Q�包含了(ji��n)拥有此��(f��)界区的线�E?ID。此字段�?(RecursionCount -1) 数��g��间的差��D��C�有多少个其他线�E�在�{�待获得该��(f��)界区�?

RecursionCount 此字�D�包含所有者线�E�已�l�获得该临界区的�ơ数。如果该数��gؓ(f��)�Ӟ��下一个尝试获取该临界区的�U�程��会(x��)成功�?

OwningThread 此字�D�包含当前占用此临界区的�U�程的线�E�标识符。此�U�程 ID �?GetCurrentThreadId 之类�?API 所�q�回�?ID 相同�?

LockSemaphore 此字�D늚�命名不恰当，它实际上是一个自复位事�g�Q�而不是一个信受��它是一个内核对象句柄，用于通知操作�pȝ��Q�该临界区现在空闌Ӏ�操作系�l�在一个线�E�第一�ơ尝试获得该临界区，但被另一个已�l�拥有该临界区的�U�程所��L��Ӟ��自动创徏�q�样一个句柄。应当调�?DeleteCriticalSection�Q�它?y��u)��发��Z��个调用该事�g�?CloseHandle 调用�Q��ƈ在必要时释放该调试结构）(j��)�Q�否则将�?x��)发生资源泄漏�?

SpinCount 仅用于多处理器系�l�。MSDN�] 文档�Ҏ(gu��)��字段�q�行如下说明�Q�“在多处理器�pȝ��中，如果该��(f��)界区不可用，调用�U�程��在对与该��(f��)界区相关的信��h��行等待操作之前，旋�{ dwSpinCount �ơ。如果该临界区在旋�{操作期间变�(sh��)ؓ(f��)可用�Q�该调用�U�程��避免了(ji��n)�{�待操作。”旋转计数可以在多处理器计算��Z��提供更佳性能�Q�其原因在于在一个��@环中旋�{通常要快于进入内核模式等待状态。此字段默认��gؓ(f��)�Ӟ��但可以用 InitializeCriticalSectionAndSpinCount API ��其讄��Z��个不同倹{�?

RTL_CRITICAL_SECTION_DEBUG �l�构

前面我们注意刎ͼ��?RTL_CRITICAL_SECTION �l�构内，DebugInfo 字段指向一�?RTL_CRITICAL_SECTION_DEBUG �l�构�Q�该�l�构�l�出如下�Q?

struct _RTL_CRITICAL_SECTION_DEBUG
{
    WORD   Type;
    WORD   CreatorBackTraceIndex;
    RTL_CRITICAL_SECTION *CriticalSection;
    LIST_ENTRY ProcessLocksList;
    DWORD EntryCount;
    DWORD ContentionCount;
    DWORD Spare[ 2 ];
}

�q�一�l�构�?InitializeCriticalSection 分配和初始化。它既可以由 NTDLL 内的预分配数�l�分配，也可以由�q�程堆分配。RTL_CRITICAL_SECTION 的这一伴随�l�构包含一�l�匹配字�D�，��h��q�然不同的角�Ԍ��(x��)有两个难以理解，随后两个提供�?ji��n)理解这一临界区链�l�构的关键，两个是重复设�|�的�Q�最后两个未使用�?

下面是对 RTL_CRITICAL_SECTION 字段的说明�?

Type 此字�D�|��使用�Q�被初始化�ؓ(f��)数�?0�?

CreatorBackTraceIndex 此字�D�仅用于诊断情�Ş中。在注册表项 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\YourProgram 之下�?keyfield、GlobalFlag �?StackTraceDatabaseSizeInMb 倹{��注意，只有在运行稍后说明的 Gflags 命��o(h��)时才�?x��)显�C��些倹{��这些注册表值的讄��正确�Ӟ��CreatorBackTraceIndex 字段��由堆栈跟踪中所用的一个烦(ch��)引值填充。在 MSDN 中搜�?GFlags 文档中的短语“create user mode stack trace database”和“enlarging the user-mode stack trace database”，可以扑ֈ�有关�q�一内容的更多信息�?

CriticalSection 指向与此�l�构相关�?RTL_CRITICAL_SECTION�?strong>�?1 说明该基��l�构以及(qi��ng) RTL_CRITICAL_SECTION、RTL_CRITICAL_SECTION_DEBUG 和事仉��中其他参与者之间的关系�?

�?1 临界区处理流�E?/strong>

ProcessLocksList LIST_ENTRY 是用于表�C�双向链表中节点的标�?Windows 数据�l�构。RTL_CRITICAL_SECTION_DEBUG 包含�?ji��n)链表的一部分�Q�允许向前和向后遍历该��(f��)界区。本文后面给出的实用工具说明如何使用 Flink�Q�前向链接）(j��)�?Blink�Q�后向链接）(j��)字段在链表中的成员�(sh��)��间移动。�Q何从事过讑֤�驱动�E�序或者研�I�过 Windows 内核的�h都会(x��)非常熟�?zh��n)��q�一数据�l�构�?

EntryCount/ContentionCount �q�些字段在相同的旉��、出于相同的原因被递增。这是那些因��Z��能马上获得��(f��)界区而进入等待状态的�U�程的数目。与 LockCount �?RecursionCount 字段不同�Q�这些字�D�|��q�都不会(x��)递减�?

Spares �q�两个字�D�|��使用�Q�甚��x(ch��ng)��被初始化�Q�尽��在删除临界区结构时��这些字�D�进行了(ji��n)清零�Q�。后面将�?x��)说明，可以用这些未被��用的字段来保存有用的诊断倹{�?

即�� RTL_CRITICAL_SECTION_DEBUG 中包含多个字�D�，它也是常规��(f��)界区�l�构的必要成分。事实上�Q�如果系�l�恰巧不能由�q�程堆中获得�q�一�l�构的存储区�Q�InitializeCriticalSection ��返回�ؓ(f��) STATUS_NO_MEMORY �?LastError �l�果�Q�然后返回处于不完整状态的临界区结构�?

临界区状�?

当程序执行、进入与��d��临界区时�Q�RTL_CRITICAL_SECTION �?RTL_CRITICAL_SECTION_DEBUG �l�构中的字段�?x��)根据�?f��)界区所处的状态变化。这些字�D는�临界�?API 中的��记代码更新�Q�在后面��会(x��)看到�q�一炏V��如果程序�ؓ(f��)多线�E�，�q�且其线�E�访问是�׃��(f��)界区保护的公用资源，则这些状态就更有意义�?

但是�Q�不��代码的�U�程使用情况如何�Q�有两种状态都�?x��)出现。第一�U�情况，如果 LockCount 字段有一个不�{�于 -1 的数��|��此��(f��)界区被占用，OwningThread 字段包含拥有该��(f��)界区的线�E�的�U�程标识�W�。在多线�E�程序中�Q�LockCount �?RecursionCount 联合表明当前有多��线�E�被��L��于该临界区。第二种情况�Q�如�?RecursionCount 是一个大�?1 的数��|��其告知�?zh��n)�所有者线�E�已�l�重新获得该临界区多��次�Q�也�怸�必要�Q�，该��(f��)界区既可以通过调用 EnterCriticalSection、也可以通过调用 TryEnterCriticalSection 获得。大�?1 的�Q何数值都表示代码的效率可能较低或者可能在以后发生错误。例如，讉K��公共资源的�Q�?C++ �c�L��法可能会(x��)不必要地重新�q�入该��(f��)界区�?

注意�Q�在大多数时间里�Q�LockCount �?RecursionCount 字段中分别包含其初始�?-1 �?0�Q�这一炚w��帔R��要。事实上�Q�对于单�U�程�E�序�Q�不能仅通过��(g��)查这些字�D�|��判断是否曾获得过临界区。但是，多线�E�程序留下了(ji��n)一些标讎ͼ�可以用来判断是否有两个或多个�U�程试图同时拥有同一临界区�?

�(zh��n)�可以找到的标记之一是即使在该��(f��)界区未被占用�?LockSemaphore 字段中仍包含一个非零倹{��这表示�Q�在某一旉��Q�此临界区阻止了(ji��n)一个或多个�U�程 �?事�g句柄用于通知该��(f��)界区已被释放�Q�等待该临界区的�U�程之一现在可以获得该��(f��)界区�q��l�执行。因�?OS 在��(f��)界区��L��另一个线�E�时自动分配事�g句柄�Q�所以如果�?zh��n)�在不再需要��(f��)界区时忘记将其删除，LockSemaphore 字段可能�?x��)导致程序中发生资源泄漏�?

在多�U�程�E�序中可能遇到的另一状态是 EntryCount �?ContentionCount 字段包含一个大于零的数倹{��这两个字段保存有��(f��)界区对一个线�E�进行阻止的�ơ数。在每次发生�q�一事�g�Ӟ��q�两个字�D�被递增�Q�但在��(f��)界区存在期间不会(x��)被递减。这些字�D�可用于间接��定�E�序的执行�\径和�Ҏ(gu��)��。例如，EntryCount 非常高时则意味着该��(f��)界区�l�历着大量争用�Q�可能会(x��)成�ؓ(f��)代码执行�q�程中的一个潜在瓶颈�?

在研�I�一个死锁程序时�Q�还?sh��)��(x��)发��C��U�似乎无法进行逻辑解释的状态。一个��用非帔R��J�的临界区的 LockCount 字段中包含一个大�?-1 的数��|��也就是说它被�U�程所拥有�Q�但�?OwningThread 字段为零�Q�这样就无法扑և�是哪个线�E�导致问题）(j��)。测试程序是多线�E�的�Q�在单处理器计算机和多处理器计算��Z��都会(x��)出现�q�种情况。尽��?LockCount 和其他值在每次�q�行中都不同�Q�但此程序��L��死锁于同一临界区。我们非常希望知道是否有��M��其他开发�h员�(sh��)��遇到�?ji��n)导致这一状态的 API 调用序列�?

构徏一个更好的捕鼠�?

在我们学�?f��n)�?f��)界区的工作方式时�Q�非常偶然地得到一些重要发玎ͼ�利用�q�些发现可以得到一个非常好的实用工兗��第一个发现是 ProcessLocksList LIST_ENTRY 字段的出玎ͼ��q��我们惛_��q�程的��(f��)界区可能是可枚�D的。另一个重大发现是我们知道�?ji��n)如何找��Z��(f��)界区列表的头。还有一个重要发现是可以在没有�Q何损��q��情况下写 RTL_CRITICAL_SECTION �?Spare 字段�Q�至��在我们的所有测试中如此�Q�。我们还发现可以很容易地重写�pȝ��的一些��(f��)界区例程�Q�而不需要对源文件进行�Q何修攏V�?

最初，我们�׃��个简单的�E�序开始，其检查一个进�E�中的所有��(f��)界区�Q��ƈ列出其当前状态，以查看是否拥有这些��(f��)界区。如果拥有，则找出由哪个�U�程拥有�Q�以�?qi��ng)该临界区阻止�?ji��n)多少个线�E�？�q�种做法对于 OS 的狂热者们比较适合�Q�但对于只是希望有助于理解其�E�序的典型的�E�序员就不是非常有用�?ji��n)�?

即��是在最��单的控制台模式“Hello World”程序中也存在许多��(f��)界区。其中大部分是由 USER32 �?GDI32 之类的系�l?DLL 创徏�Q�而这�?DLL 很少�?x��)导致死锁或性能问题。我们希望有一�U�方法能滤除�q�些临界区，而只留下代码中所兛_��(j��)的那些��(f��)界区。RTL_CRITICAL_SECTION_DEBUG �l�构中的 Spare 字段可以很好地完成这一工作。可以��用其中的一个或两个来指�C�：(x��)�q�些临界区是来自用户�~�写的代码，而不是来�?OS�?

于是�Q�下一个逻辑问题��变?sh��)��如何确定哪些�?f��)界区是来自�?zh��n)��~�写的代码。有些读者可能还记得 Matt Pietrek 2001 �q?1 月的 Under The Hood 专栏中的 LIBCTINY.LIB。LIBCTINY 所采用的一个技巧是一�?LIB 文�g�Q�它重写�?ji��n)关�?Visual C++ �q�行时例�E�的标准实现。将 LIBCTINY.LIB 文�g�|�于链接器行的其�?LIB 之前�Q�链接器��用这一实现�Q�而不是��?Microsoft 所提供的导入库中的同名后箋(hu��)版本�?

为对临界区应用类似技巧，我们创徏 InitializeCriticalSection 的一个替代版本及(qi��ng)其相兛_��入库。将�?LIB 文�g�|�于 KERNEL32.LIB 之前�Q�链接器��链接我们的版本�Q�而不�?KERNEL32 中的版本。对 InitializeCriticalSection 的实现显�C�在�?2 中。此代码在概念上非常��单。它首先调用 KERNEL32.DLL 中的实际 InitializeCriticalSection。接下来�Q�它获得调用 InitializeCriticalSection 的代码地址�Q��ƈ��其贴至 RTL_CRITICAL_SECTION_DEBUG �l�构的备用字�D�之一。我们的代码如何��定调用代码的地址呢？x86 CALL 指��o(h��)��返回地址�|�于堆栈中。CriticalSectionHelper 代码知道该返回地址位于堆栈帧中一个已知的固定位置�?

实际�l�果是：(x��)�?CriticalSectionHelper.lib 正确链接的�Q�?EXE �?DLL 都将导入我们�?DLL (CriticalSectionHelper.DLL)�Q��ƈ占用应用�?ji��n)备用字�D늚�临界区。这样就使事情简单了(ji��n)许多。现在我们的实用工具可以��单地遍历�q�程中的所有��(f��)界区�Q��ƈ且只昄��h��正确填充的备用字�D늚�临界��Z��息。那么需要�ؓ(f��)�q�一实用工具付出什么代价呢�Q�请�E�等�Q�还有更多的内容�Q?

因�ؓ(f��)�(zh��n)�的所有��(f��)界区现在都包含对其进行初始化时的地址�Q�实用工具可以通过提供其初始化地址来识别各个��(f��)界区。原始代码地址本��n没有那么有用。幸�q�的是，DBGHELP.DLL 使代码地址向源文�g、行号和函数名称的�{换变得非常容易。即使一个��(f��)界区中没有�?zh��n)�在其中的�{�֐��Q�也可以��其地址提交�l?DBGHELP.DLL。如果将其声明�ؓ(f��)一个全局变量�Q��ƈ且如果符号可用，则�?zh��n)��可以在原始源代码中��定临界区的名称。顺便说明一下，如果通过讄�� _NT_SYMBOL_PATH 环境变量�Q��ƈ讄�� DbgHelp 以��用其 Symbol Server 下蝲功能�Q�从而�� DbgHelp 发挥其效用，则会(x��)得到非常好的�l�果�?

MyCriticalSections 实用工具

我们��所有这些思想�l�合��h��Q�提��Z��(ji��n) MyCriticalSections �E�序。MyCriticalSections 是一个命令行�E�序�Q�在不��用参数运行该�E�序时可以看��C��些选项�Q?

Syntax: MyCriticalSections  [options]
        Options:
        /a = all critical sections
        /e = show only entered critical sections
        /v = verbose

唯一需要的参数�?Program ID �?PID�Q�十�q�制形式�Q�。可以用多种�Ҏ(gu��)��获得 PID�Q�但最��单的�Ҏ(gu��)��可能��是通过 Task Manager。在没有其他选项�Ӟ��MyCriticalSections 列出�?ji��n)来自代码模块的所有��(f��)界区状态，�(zh��n)�已�l�将 CriticalSectionHelper.DLL 链接臌��些代码模块。如果有可用于这一�Q�些�Q�模块的�W�号�Q�代码将��试提供该��(f��)界区的名�U�ͼ�以及(qi��ng)对其�q�行初始化的位置�?
要查�?MyCriticalSections 是如何�v作用的，误��?Demo.EXE �E�序�Q�该�E�序包含在下载文件中。Demo.EXE 只是初始化两个��(f��)界区�Q��ƈ�׃��对线�E�进入这两个临界区�?a >�?3 昄��q�行“MyCriticalSections 2040”的�l�果�Q�其�?2040 �?Demo.EXE �?PID�Q��?
在该图中�Q�列��Z��(ji��n)两个临界区。在本例中，它们被命名�ؓ(f��) csMain �?yetAnotherCriticalSection。每个“Address:”行昄��?CRITICAL_SECTION 的地址�?qi��ng)其名称。“Initialized in”行包含�?ji��n)在其中初始�?CRITICAL_SECTION 的函数名。代码的“Initialized at”行昄��?ji��n)源文�g和初始化函数中的行号�?
对于 csMain 临界区，�(zh��n)�将看到锁定��Cؓ(f��) 0、递归��Cؓ(f��) 1�Q�表�C�Z��个已�l�被一�U�程获得的��(f��)界区�Q��ƈ且没有其他线�E�在�{�待该��(f��)界区。因��Z��来没有线�E�被��L��于该临界区，所�?Entry Count 字段�?0�?
现在来看 yetAnotherCriticalSection�Q�会(x��)发现光��归��Cؓ(f��) 3。快速浏�?Demo 代码可以看出�Q�主�U�程调用 EnterCriticalSection 三次�Q�所以事情的发生与预期一致。但是，�q�有一个第二线�E�试图获得该临界区，�q�且已经被阻止。同��P��LockCount 字段也�ؓ(f��) 3。此输出昄��有一个等待线�E��?
MyCriticalSections 拥有一些选项�Q��其对于更为勇敢的探烦(ch��)者非常有用�?v 开��x(ch��ng)��C�每个��(f��)界区的更多信息。旋转数与锁定信号字�D�尤为重要。�?zh��n)��l�常�?x��)看�?NTDLL 和其�?DLL 拥有一些旋转数非零的��(f��)界区。如果一个线�E�在获得临界区的�q�程中曾被锁定，则锁定信号字�D��ؓ(f��)非零倹{�?v 开兌��昄��?RTL_CRITICAL_SECTION_DEBUG �l�构中备用字�D늚�内容�?
/a 开��x(ch��ng)��C��E�中的所有��(f��)界区�Q�即使其中没�?CriticalSectionHelper.DLL �{�֐�也会(x��)昄��。如果��?/a�Q�则请做好有大量输出的准备。真正的黑客希望同时使用 /a �?/v�Q�以昄��q�程中全部内容的最多细节。��?/a 的一个小��的好处是会(x��)看到 NTDLL 中的LdrpLoaderLock 临界区。此临界区在 DllMain 调用和其他一些重要时间内被占用。LdrpLoaderLock 是许多不太明显、表面上难以解释的死锁的形成原因之一。（��Z�� MyCriticalSection 能够正确标记 LdrpLoaderLock 实例�Q�需要用�?NTDLL �?PDB 文�g可供使用。）(j��)
/e 开关�ɽE�序仅显�C�当前被占用的��(f��)界区。未使用 /a 开��x(ch��ng)��Q�只昄��代码中被占用的��(f��)界区�Q�如备用字段中的�{�֐�所指示�Q�。采�?/a 开��x(ch��ng)��Q�将昄��q�程中的全部被占用��(f��)界区�Q�而不考虑其来源�?
那么�Q�希望什么时候运�?MyCriticalSections 呢？一个很明确的时间是在程序被死锁时。检查被占用的��(f��)界区�Q�以查看是否有什么��(zh��n)�惊讶的事情。即使被死锁的程序正�q�行于调试器的控制之下，也可以��?MyCriticalSections�?
另一�U��?MyCriticalSections 的时机是在对有大量多�U�程的程序进行性能调整时。在��d��于调试器中的一个��用频�J�、非重入函数�Ӟ��q�行 MyCriticalSections�Q�查看在该时��d��用了(ji��n)哪些临界区。如果有很多�U�程都执行相同�Q务，��非常容易导致一�U�情形：(x��)一个线�E�的大部分时间被消耗在�{�待获得一个��用频�J�的临界��Z��。如果有多个使用频繁的��(f��)界区�Q�这造成的后果就像花园的��水软管打了(ji��n)�l�一栗��解决一个争用问题只是将问题转移��C��一个容易造成��d��的��(f��)界区�?
一个查看哪些��(f��)界区最�Ҏ(gu��)��D��争用的好�Ҏ(gu��)��是在接近�E�序�l�尾处设�|�一个断炏V��在遇到断点�Ӟ��q�行 MyCriticalSections �q�查扑օ�有最�?Entry Count 值的临界区。正是这些��(f��)界区��D��?ji��n)大多数��d��和线�E��{换�?
��管 MyCriticalSections �q�行�?Windows 2000 �?qi��ng)更新版本，但�(zh��n)�仍需要一个比较新�?DbgHelp.DLL 版本 �Q?5.1 版或更新版本。Windows XP 中提供这一版本。也可以由其他��?DbgHelp 的工具中获得该版本。例如，Debugging Tools For Windows 下蝲中通常拥有最新的 DbgHelp.DLL�?
深入研究重要的��(f��)界区例程
此最后一节是为那些希望理解��(f��)界区实现内幕的勇敢读者提供的。对 NTDLL �q�行仔细研究后可以�ؓ(f��)�q�些例程�?qi��ng)其支持子例�E�创��Z��码（见下载中�?NTDLL(CriticalSections).cpp�Q�。以�?KERNEL32 API �l�成临界区的公共接口�Q?
InitializeCriticalSection InitializeCriticalSectionAndSpinCount DeleteCriticalSection TryEnterCriticalSection EnterCriticalSection LeaveCriticalSection

前两�?API 只是分别围绕 NTDLL API RtlInitializeCriticalSection �?RtlInitializeCriticalSectionAndSpinCount 的瘦包装。所有剩余例�E�都被提交给 NTDLL 中的函数。另外，�?RtlInitializeCriticalSection 的调用是另一个围�l?RtlInitializeCriticalSectionAndSpinCount 调用的瘦包装�Q�其旋�{数的��gؓ(f��) 0。��用��(f��)界区的时候实际上是在�q�后使用以下 NTDLL API�Q?
RtlInitializeCriticalSectionAndSpinCount RtlEnterCriticalSection RtlTryEnterCriticalSection RtlLeaveCriticalSection RtlDeleteCriticalSection

在这一讨论中，我们采用 Kernel32 名称�Q�因为大多数 Win32 �E�序员对它们更�ؓ(f��)熟�?zh��n)��?
InitializeCriticalSectionAndSpinCount 对��(f��)界区的初始化非常��单。RTL_CRITICAL_SECTION �l�构中的字段被赋予其起始倹{��与此类��|��分配 RTL_CRITICAL_SECTION_DEBUG �l�构�q�对其进行初始化�Q�将 RtlLogStackBackTraces 调用中的�q�回��D��?CreatorBackTraceIndex�Q��ƈ建立到前面��(f��)界区的链接�?
��Z��说一壎ͼ�CreatorBackTraceIndex 一般接收到的��gؓ(f��) 0。但是，如果�?Gflags �?Umdh 实用工具�Q�可以输入以下命令：(x��)
Gflags /i MyProgram.exe +ust Gflags /i MyProgram.exe /tracedb 24

�q�些命��o(h��)使得 MyProgram 的“Image File Execution Options”下��d��?ji��n)注册表��V��在下一�ơ执�?MyProgram 时会(x��)看到此字�D�|��收到一个非 0 数倹{��有��x(ch��ng)��多信息，参阅知识库文�?Q268343�?a >Umdhtools.exe:How to Use Umdh.exe to Find Memory Leaks”。��(f��)界区初始化中另一个需要注意的问题是：(x��)�?64 �?RTL_CRITICAL_SECTION_DEBUG �l�构不是��p��E�堆中分配，而是来自位于 NTDLL 内的 .data 节的一个数�l��?
在完成��(f��)界区的��用之后，�?DeleteCriticalSection�Q�其命名不当�Q�因为它只删�?RTL_CRITICAL_SECTION_ DEBUG�Q�的调用遍历一个同样可理解的�\径。如果由于线�E�在��试获得临界区时被阻止而创��Z��(ji��n)一个事�Ӟ��通过调用 ZwClose 来销毁该事�g。接下来�Q�在通过 RtlCriticalSectionLock 获得保护之后�Q�NTDLL 以一个��(f��)界区保护它自��q��内部临界区列�?�?�(zh��n)�猜对了(ji��n)�Q�，��调试信息从链中清除�Q�对该��(f��)界区链表�q�行更新�Q�以反映对该信息的清除操作。该内存��q��值填充，�q�且如果其存储区是由�q�程堆中获得�Q�则调用 RtlFreeHeap ��得其内存被释放。最后，以零填充 RTL_CRITICAL_SECTION�?
有两�?API 要获得受临界��Z��护的资源 �?TryEnterCriticalSection �?EnterCriticalSection。如果一个线�E�需要进入一个��(f��)界区�Q�但在等待被��L��资源变�(sh��)ؓ(f��)可用的同�Ӟ��可执行有用的工作�Q�那�?TryEnterCriticalSection 正是�(zh��n)�需要的 API。此例程��试此��(f��)界区是否可用�Q�如果该临界��占用�Q�该代码��返回�?FALSE�Q��ؓ(f��)该线�E�提供��l�执行另一��d��的机�?x��)。否则，其作用只是相当于 EnterCriticalSection�?
如果该线�E�在�l�箋(hu��)�q�行之前��实需要拥有该资源�Q�则使用 EnterCriticalSection。此�Ӟ��取消用于多处理器计算机的 SpinCount ��试。这一例程�?TryEnterCriticalSection �c�M��Q�无��临界区是�I�闲的或已经被该�U�程所拥有�Q�都调整对该临界区的��记。注意，最重要�?LockCount 递增是由 x86“lock”前�~�完成的，�q�一炚w��帔R��要。这��保�?ji��n)在某一旉��内只有一�?CPU 可以修改�?LockCount 字段。（事实上，W(xu��)in32 InterlockedIncrement API 只是一个具有相同锁定前�~��?ADD 指��o(h��)。）(j��)
如果调用�U�程无法立即获得该��(f��)界区�Q�则调用 RtlpWaitForCriticalSection ��该�U�程�|�于�{�待状态。在多处理器�pȝ��中，EnterCriticalSection 旋�{ SpinCount 所指定的次敎ͼ��q�在每次循环讉K��中测试该临界区的可用性。如果此临界区在循环期间变�(sh��)ؓ(f��)�I�闲�Q�该�U�程获得该��(f��)界区�Q��ƈ�l�箋(hu��)执行�?
RtlpWaitForCriticalSection 可能是这里所�l�的所有过�E�中最为复杂、最为重要的一个。这�q�不值得大惊��怪，因�ؓ(f��)如果存在一个死锁�ƈ涉及(qi��ng)临界区，则利用调试器�q�入该进�E�就可能昄��?RtlpWaitForCriticalSection �?ZwWaitForSingleObject 调用中的臛_��一个线�E��?
如伪码中所昄��Q�在 RtlpWaitForCriticalSection 中有一点簿记工作，如递增 EntryCount �?ContentionCount 字段。但更重要的是：(x��)发出�?LockSemaphore 的等待，以及(qi��ng)对等待结果的处理。默认情冉|��一个空指针作�ؓ(f��)�W�三个参��C��递给 ZwWaitForSingleObject 调用�Q�请求该�{�待永远不要��时。如果允许超�Ӟ��生成调试消息字�W�串�Q��ƈ再次开始等待。如果不能从�{�待中成功返回，��׃��(x��)产生中止该进�E�的错误。最后，在从 ZwWaitForSingleObject 调用中成功返回时�Q�则执行�?RtlpWaitForCriticalSection �q�回�Q�该�U�程现在拥有该��(f��)界区�?
RtlpWaitForCriticalSection 必须认识到的一个��(f��)界条件是该进�E�正在被关闭�Q��ƈ且正在等待加载程序锁�?(LdrpLoaderLock) 临界区。RtlpWaitForCriticalSection 一�?em>不能允许该线�E�被��L��Q�但是必��蟩�q�该�{�待�Q��ƈ允许�l�箋(hu��)�q�行关闭操作�?
LeaveCriticalSection 不像 EnterCriticalSection 那样复杂。如果在递减 RecursionCount 之后�Q�结果不�?0�Q�意味着该线�E�仍然拥有该临界区）(j��)�Q�则该例�E�将�?ERROR_SUCCESS 状态返回。这��是��Z��么需要用适当数目�?Leave 调用来��^�?Enter 调用。如果该计数�?0�Q�则 OwningThread 字段被清�Ӟ��LockCount 被递减。如果还有其他线�E�在�{�待�Q�例�?LockCount 大于或等�?0�Q�则调用 RtlpUnWaitCriticalSection。此帮助器例�E�创�?LockSemaphore�Q�如果其��未存在�Q�，�q�发�?gu��)��信号提醒操作�pȝ��Q�该�U�程已经释放该��(f��)界区。作为通知的一部分�Q�等待线�E�之一退出等待状态，��行做好准备�?
最后要说明的一�Ҏ(gu��)��Q�MyCriticalSections �E�序如何��定临界区链的�v始呢�Q�如果有权访�?NTDLL 的正��调试符��P��则对该列表的查找和遍历非常简单。首先，定位�W�号 RtlCriticalSectionList�Q�清�I�其内容�Q�它指向�W�一�?RTL_CRITICAL_SECTION_DEBUG �l�构�Q�，�q�开始遍历。但是，�q�不是所有的�pȝ��都有调试�W�号�Q�RtlCriticalSectionList 变量的地址�?x��)�?Windows 的各个版本而发生变化。�ؓ(f��)�?ji��n)提供一�U�对所有版本都能正常工作的解决�Ҏ(gu��)��Q�我们设计了(ji��n)以下试探性方案。观察启动一个进�E�时所采取的步骤，�?x��)看到是以以下顺序�?NTDLL 中的临界��行初始化的（�q�些名称取自 NTDLL 的调试符��P��(j��)�Q?
RtlCriticalSectionLock DeferedCriticalSection (this is the actual spelling!) LoaderLock FastPebLock RtlpCalloutEntryLock PMCritSect UMLogCritSect RtlpProcessHeapsListLock

因�ؓ(f��)��(g��)查进�E�环境块 (PEB) 中偏�U�量 0xA0 处的地址��可以找到加载程序锁�Q�所以对该链起始位置的定位就变得比较��单。我们读取有兛_��载程序锁的调试信息，然后沿着铑֐�后遍历两个链接，使我们定位于 RtlCriticalSectionLock ��，在该点得到该铄��W�一个��(f��)界区。有兛_��Ҏ(gu��)��的说明，请参�?strong>�?4�?

�?4 初始化顺�?/strong>

��结

几乎所有的多线�E�程序均使用临界区。�?zh��n)��q�早都会(x��)遇到一个��代码死锁的��(f��)界区�Q��ƈ且会(x��)难以��定是如何进入当前状态的。如果能够更深入��C��(ji��n)解��(f��)界区的工作原理，则这一情�Ş的出现就不会(x��)像首�ơ出现时那样的��o(h��)人沮丧。�?zh��n)�可以研究一个看来非常含�p�的临界区，�q�确定是谁拥有它�Q�以�?qi��ng)其他有用细节。如果�?zh��n)�愿意��我们的库加入�(zh��n)�的链接器行，则可以容易地获得有关�?zh��n)�程序��(f��)界区使用的大量信息。通过利用临界区结构中的一些未用字�D�，我们的代码可以仅隔离�q�命名�?zh��n)�的模块所用的临界区，�q�告知其准确状态�?

有魄力的读者可以很�Ҏ(gu��)��地对我们的代码进行扩展，以完成更为异乎寻常的工作。例如，采用�?InitializeCriticalSection 挂钩相类似的方式截获 EnterCriticalSection �?LeaveCriticalSection�Q�可以存储最后一�ơ成功获得和释放该��(f��)界区的位�|�。与此类��|��CritSect DLL 拥有一个易于调用的 API�Q�用于枚举�?zh��n)�自己的代码中的�?f��)界区。利�?.NET Framework 中的 Windows �H�体�Q�可以相对容易地创徏一�?GUI 版本�?MyCriticalSections。对我们代码�q�行扩展的可能性非常大�Q�我们非�怹�意看到其他�h员所发现和创造的创新性办法�?

有关文章�Q�请参阅�Q?/strong>
Global Flag Reference:Create kernel mode stack trace database
GFlags Examples:Enlarging the User-Mode Stack Trace Database
Under the Hood:Reduce EXE and DLL Size with LIBCTINY.LIB

Matt Pietrek 是一位��Y件架构师和作者。他��p��?Compuware/NuMega 实验室，�w�䆾�?BoundsChecker 和“分布式分析器”��品的首席架构师。他已经创作�?ji��n)三本有�?Windows �pȝ��~�程的书�c�，�q�是 MSDN Magazine 的特�U�编辑。他�?Web 站点 (http://www.wheaty.net) 有关于以前文章和专栏�?FAQ 和信息�?

Jay Hilyard �?Compuware/NuMega 实验室的 BoundsChecker ��组的��Y件工�E�师。他、他的妻子和他们的猫是新�|�布什��?d��ng)州的新居民。他的联�p�L��式�ؓ(f��) RussOsterlund@adelphia.net �?Web 站点 http://www.smidgeonsoft.com�?

转到原英文页�?/a>

jans2002 2009-02-20 10:03 发表评论

如何�Ҏ(gu��)��E�序崩溃时的DMP文�g使用WinDbg查找调用堆栈

jans2002 — Thu, 08 Jan 2009 07:53:00 GMT

HOW TO�Q?查找问题的异常堆栈时出现�?UnhandledExceptionFilter 调用堆栈跟踪�?/h3>
http://support.microsoft.com/kb/313109/zh-cn

察看本文应用于的产品

本页

概要

使用 Windbg.exe 打开转储文�g

使用 Windbg.exe ��定异常堆栈

参�?/a>

展开全部 | 关闭全部

概要
没有异常处理�E�序定义处理引发的异常时�Q�将调用�?UnhandledExceptionFilter 函数�?通常�Q�该函数�?x��)将异常传递给�?Ntdll.dll 为文...

没有异常处理�E�序定义处理引发的异常时�Q�将调用�?UnhandledExceptionFilter 函数�?通常�Q�该函数�?x��)将异常传递给�?Ntdll.dll 为文件其中捕��P��q�尝试处理设�|��?
在进�E�的内存快照所在某些情况下�Q�可以看到锁定点保存到线�E�的�U�程的调�?UnhandledExceptionFilter 函数�?在这的种情况下�?zh��n)�可以按照本文以确定导致此异常�?DLL�?
回到��端
使用 Windbg.exe 打开转储文�g

下蝲�q�安装调试程序�?要下载调试程序，误��问下面的 Microsoft �|�站�Q?
Microsoft 调试工具
http://www.microsoft.com/whdc/devtools/ddk/default.mspx (http://www.microsoft.com/whdc/devtools/ddk/default.mspx)

打开安装调试�E�序�Q�文件夹�Q�然后双�?Windbg.exe 启动调试器�?
�?文�g 菜单上单�?打开的崩溃�{�?�Q�或�?Ctrl+D�Q�，然后选择要查看该转储文�g�?/li>

回到��端
使用 Windbg.exe ��定异常堆栈

�?Windbg.exe�Q�打开�q�程�?dmp 文�g�?
��L(f��ng)��保�?zh��n)��W�号路径指向正确的位�|��?有关如何执行此操作，误��问下面的 Microsoft Web 站点�Q?
如何获得�W�号
http://www.microsoft.com/whdc/devtools/ddk/default.mspx (http://www.microsoft.com/whdc/devtools/ddk/default.mspx)

在命令提�C�符下键�?~ * kb 以列出所有进�E�中的线�E��?
标识对函数调用的�U�程 Kernel32! UnhandledExceptionFilter �?它类��g��以下�Q?
120 id: f0f0f0f0.a1c Suspend: 1 Teb 7ff72000 Unfrozen ChildEBP RetAddr Args to Child 09a8f334 77eb9b46 0000244c 00000001 00000000 ntdll!ZwWaitForSingleObject+0xb [i386\usrstubs.asm @ 2004] 09a8f644 77ea7e7a 09a8f66c 77e861ae 09a8f674 KERNEL32!UnhandledExceptionFilter+0x2b5 [D:\nt\private\windows\base\client\thread.c @ 1753] 09a8ffec 00000000 787bf0b8 0216fe94 00000000 KERNEL32!BaseThreadStart+0x65 [D:\nt\private\windows\base\client\support.c @ 453]

切换到该�U�程 �Q�在本例中，该线�E�是"~120s"�Q��?
在第一个参数的指定位置昄��内存内容 Kernel32! UnhandledExceptionFilter 通过 ��d�� �W�一个参�?�?此指�?EXCEPTION_POINTERS �l�构
0:120> dd 09a8f66c 09a8f66c 09a8f738 09a8f754 09a8f698 77f8f45c 09a8f67c 09a8f738 09a8ffdc 09a8f754 09a8f710 09a8f68c 09a8ffdc 77f8f5b5 09a8ffdc 09a8f720 09a8f69c 77f8f3fa 09a8f738 09a8ffdc 09a8f754 09a8f6ac 09a8f710 77e8615b 09a8fad4 00000000 09a8f6bc 09a8f738 74a25336 09a8f6e0 09a8f910 09a8f6cc 01dc8ad8 0d788918 00000001 018d1f28 09a8f6dc 00000001 61746164 7073612e 09a8f71c

�W�一�?DWORD 代表异常记录�?若要获取有关异常的类型信息，误��在命令提�C�符处运行以下：(x��)
.exr first DWORD from step 6
0:120> .exr 09a8f738 ExceptionAddress: 78011f32 (MSVCRT!strnicmp+0x00000092) ExceptionCode: c0000005 ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 00000000 Attempt to read from address 00000000

�W�二�?DWORD 是上下文记录�?若要获取上下文的信息�Q�请在命令提�C�符处运行以下：(x��)
.cxr second DWORD from step 6
0:120> .cxr 09a8f754 eax=027470ff ebx=7803cb28 ecx=00000000 edx=00000000 esi=00000000 edi=09a8fad4 eip=78011f32 esp=09a8fa20 ebp=09a8fa2c iopl=0 nv up ei ng nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010286 MSVCRT!strnicmp+92: 78011f32 8a06 mov al,[esi]

�q�行 kv 命��o(h��)获得实际的异常的调用堆栈�?�q�有助于�(zh��n)�识别可能未被处理正��的�q�程中实际问�?
0:120> kv ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 09a8fa2c 780119ab 09a8fad4 00000000 09a8faa8 MSVCRT!strnicmp+0x92 09a8fa40 7801197c 09a8fad4 00000000 6d7044fd MSVCRT!stricmp+0x3c 09a8fa80 6e5a6ef6 09a8fad4 2193d68d 00e5e298 MSVCRT!stricmp+0xd 09a8fa94 6d7043bf 09a8fad4 09a8faa8 0000001c IisRTL!CLKRHashTable::FindKey+0x59 (FPO: [2,0,1]) 09a8faac 749fc22d 09a8fad4 01d553b0 0000001c ISATQ!CDirMonitor::FindEntry+0x1e (FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\infocomm\atq\dirmon.cpp @ 884] 09a8fac4 749fd1cb 09a8fad4 09a8fb10 525c3a46 asp!RegisterASPDirMonitorEntry+0x6e (FPO: [EBP 0x09a8fb08] [2,0,4]) [D:\nt\private\inet\iis\svcs\cmp\asp\aspdmon.cpp @ 534] 09a8fb08 749fcdd6 00000000 09a8fcbc 018d1f28 asp!CTemplateCacheManager::RegisterTemplateForChangeNotification+0x8a (FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\cmp\asp\cachemgr.cpp @ 621] 09a8fb3c 74a08bfe 00000000 000000fa 74a30958 asp!CTemplateCacheManager::Load+0x382 (FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\cmp\asp\cachemgr.cpp @ 364] 09a8fc68 74a0d4c9 04c12518 018d1f28 09a8fcbc asp!LoadTemplate+0x42 (FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\cmp\asp\exec.cpp @ 1037] 09a8fcc0 74a2c3e5 00000000 0637ee38 09a8fd58 asp!CHitObj::ViperAsyncCallback+0x3e8 (FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\cmp\asp\hitobj.cpp @ 2414] 09a8fcd8 787c048a 00000000 77aa1b03 01e91ed8 asp!CViperAsyncRequest::OnCall+0x3f (FPO: [Non-Fpo]) [D:\nt\private\inet\iis\svcs\cmp\asp\viperint.cpp @ 194] 09a8fce0 77aa1b03 01e91ed8 77a536d8 00000000 COMSVCS!STAActivityWorkHelper+0xa (FPO: [1,0,0]) 09a8fd24 77aa1927 000752f8 000864dc 787c0480 ole32!EnterForCallback+0x6a (FPO: [Non-Fpo]) [D:\nt\private\ole32\com\dcomrem\crossctx.cxx @ 1759] 09a8fe50 77aa17ea 000864dc 787c0480 01e91ed8 ole32!SwitchForCallback+0x12b (FPO: [Non-Fpo]) [D:\nt\private\ole32\com\dcomrem\crossctx.cxx @ 1644] 09a8fe78 77aa60c1 000864dc 787c0480 01e91ed8 ole32!PerformCallback+0x50 (FPO: [Non-Fpo]) [D:\nt\private\ole32\com\dcomrem\crossctx.cxx @ 1559] 09a8fed4 77aa5fa6 04f2b4c0 787c0480 01e91ed8 ole32!CObjectContext::InternalContextCallback+0xf5 (FPO: [Non-Fpo]) [D:\nt\private\ole32\com\dcomrem\context.cxx @ 3866] 09a8fef4 787bd3c3 04f2b4c0 787c0480 01e91ed8 ole32!CObjectContext::DoCallback+0x1a (FPO: [Non-Fpo]) [D:\nt\private\ole32\com\dcomrem\context.cxx @ 3746] 09a8ff24 787bf373 0216fb3c 00000007 09a8ffec COMSVCS!STAActivityWork::DoWork+0x73 (FPO: [0,4,2]) 09a8ffb4 77e8758a 0216fe94 0216fb3c 00000007 COMSVCS!STAThread::STAThreadWorker+0x2bb (FPO: [EBP 0x09a8ffec] [1,31,4]) 09a8ffec 00000000 787bf0b8 0216fe94 00000000 KERNEL32!BaseThreadStart+0x52 (FPO: [Non-Fpo]) [D:\nt\private\windows\base\client\support.c @ 451]

jans2002 2009-01-08 15:53 发表评论

jans2002 — Thu, 25 Dec 2008 02:08:00 GMT

虽然�|�上关于boost�~�译问题的文章一堆一堆的�Q�但是到我��用的时候怎么��׃��行呢�Q�我的编译器是vc7.1�Q�本来不想用boost�Q�只是�ؓ(f��)�?ji��n)编译asio的例子，引用�?/p>
#include

�q�个头文�Ӟ��招来了(ji��n)一堆的问题

提示链接错误�Q?/p>
文�glibboost_date_time-vc71-mt-sgd-1_37.lib找不�?/p>
然后��开始了(ji��n)漫长的boost库编译�?/p>
但是�~�译完了(ji��n)�Q�提�C��是找不到�Q�我晕。查�?ji��n)查sgd的意�?/p>
s:代表static

gd:代表调试�?/p>
�|�上的说�?/a>我照着做了(ji��n)�Q�根本就不行�Q�不知道是笔误呢�Q�还是bjam版本已经更新�?ji��n)。只好根据错误提�C�，在boost的Jam文�g中来揣测�~�译开�?/p>
在X:\boost_1_37_0\tools\build\v2\build目录中的build-request.jam文�g�?48行有

feature toolset : gcc msvc borland : implicit ;�{�内�?/p>
哦，�q�个大概��是�~�译开关了(ji��n)

下面是编译出�?r��n)态链接的release版本

bjam toolset=msvc-7.1 runtime-link=static stage

下面是编译出�?r��n)态链接的debug版本

bjam toolset=msvc-7.1 debug runtime-link=static stage

�q�个stage开兛_��Q�可能就是把�~�译出来的文件复制到目录

X:\boost_1_37_0\stage\lib

其它的开�?/p>
rtti:on off

optimization: on off

�{�等�Q?/p>

jans2002 2008-12-25 10:08 发表评论

jans2002 — Thu, 18 Dec 2008 02:29:00 GMT

最�q�在开发一个ActiveX视频控�g�Q�需要有全屏功能�Q�因为用到好几层�H�口�Q�在全屏的时候费�?ji��n)很多周折，最后瞎凑�ȝ��凑好�?ji��n)，写下来与大家�׃�n�?/p>
让应用程序全屏显�C�其实思�\很简单：(x��)

1.先保存要全屏的窗口的父窗�?/p>
2.如果要全屏的�H�口不是子窗口，讄��光��gؓ(f��)WS_CHILD

3.讄��H�口的父�H�口为桌�?::GetDesktopWindow())

4.�U�d��H�口臛_��屏，�q�将�H�口设�ؓ(f��)��d��最上HWND_TOPMOST

m_videoMgr是我控�g里创建的视频�H�口�Q�它的父�H�口是控件窗�?CameraControl)控�g本��n的窗口不直接昄��Q�被�q�个m_videoMgr�H�口完全覆盖。在全屏的时候，如果直接更改CameraControl的父�H�口�Q�它的子�H�口m_videoMgr�H�口��L��不能正确的设�|��ؓ(f��)全屏�Q�可能在控�g��试容器里正常，但是��C��(ji��n)IE里就不正�怺�(ji��n)。于是我改�ؓ(f��)更改m_videoMgr�H�口的父�H�口�Q�保留控件本�w�窗口，但是改变�H�口大小的时候，改变父窗口的大小�Q�也许m_videoMgr�H�口可能和控件本�w�窗口的大小有关联，�q�样成功的进行了(ji��n)全屏�Q�而且不管是在IE和控件测试容器里都可以正常的全屏和恢复�?/p>

if(bFullScreen) { //获取控�g�H�口的绝对位�|?/span>
GetWindowRect(m_rcCtrlRect); ::SetParent(m_videoMgr.GetSafeHwnd(),::GetDesktopWindow()); int cx = ::GetSystemMetrics(SM_CXSCREEN); int cy = ::GetSystemMetrics(SM_CYSCREEN); MoveWindow(0, 0, cx, cy); ::SetWindowPos(m_videoMgr.GetSafeHwnd(),HWND_TOPMOST,0,0,cx,cy,SWP_FRAMECHANGED|SWP_DEFERERASE); m_bFullScreen = TRUE; } else { ::SetParent(m_videoMgr.GetSafeHwnd(),m_hWnd);
//MoveWindow使用相对�H�口坐标�Q�所以必��d��转化为相对坐�?/span>
CPoint LeftTop(m_rcCtrlRect.TopLeft()); CPoint BottomRight(m_rcCtrlRect.BottomRight()); ::ScreenToClient(m_hWnd,&LeftTop); ::ScreenToClient(m_hWnd,&BottomRight); ::MoveWindow(m_hWnd,LeftTop.x,LeftTop.y,m_rcCtrlRect.Width(),m_rcCtrlRect.Height(),TRUE); ::SetWindowPos(m_videoMgr.GetSafeHwnd(),HWND_NOTOPMOST,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE); m_bFullScreen = FALSE; }

解决�?ji��n)上面的问题�(sh��)��后�Q�又发现�?ji��n)一个新的问题，��是全屏以后想��用Esc键退出全屏时�Q�根本不响应键盘消息�Q�后来发现MFC也有控�g不处理键盘消息的问题�Q�想惛_��能跟控�g的焦�Ҏ(gu��)��关系�Q�于是在FullScreen的之前，加一个SetFocus()
if(FullScreen&&!IsFullScreen()) { SetFocus(); OnFullScreen(TRUE); }
然后发现键盘消息处理正常�?ji��n)，问题解决�?/pre>

jans2002 2008-12-18 10:29 发表评论

97久久精品人人澡人人爽,精品国产日韩久久亚洲,久久综合伊人77777

(�?一个小技巧：(x��)SFP Overwrite�Q�以c语言为实例）(j��)

���单的makefile例子

如何�Ҏ(gu��)���E�序崩溃时的DMP文�g使用WinDbg查找调用堆栈

HOW TO�Q?查找问题的异常堆栈时出现�?UnhandledExceptionFilter 调用堆栈跟踪�?/h3> http://support.microsoft.com/kb/313109/zh-cn 察看本文应用于的产品

本页

概要 没有异常处理�E�序定义处理引发的异常时�Q�将调用�?UnhandledExceptionFilter 函数�?通常�Q�该函数�?x��)将异常传递给�?Ntdll.dll 为文...

使用 Windbg.exe 打开转储文�g

使用 Windbg.exe ���定异常堆栈

��单的makefile例子

如何�Ҏ(gu��)��E�序崩溃时的DMP文�g使用WinDbg查找调用堆栈

HOW TO�Q?查找问题的异常堆栈时出现�?UnhandledExceptionFilter 调用堆栈跟踪�?/h3>
http://support.microsoft.com/kb/313109/zh-cn

察看本文应用于的产品

概要
没有异常处理�E�序定义处理引发的异常时�Q�将调用�?UnhandledExceptionFilter 函数�?通常�Q�该函数�?x��)将异常传递给�?Ntdll.dll 为文...

使用 Windbg.exe ��定异常堆栈