WOW64（Windows-On-Windows 64bit）是X64 Windows操作系统的一个子系统，为32位应用程序提供运行环境。类似的还有WOW32子系统，负责在32位Windows系统上运行16位应用程序。

WoW64存在的原因还要从CPU的发展上开始说，X86指令集是一个指令集架构家族，最初在Intel 8086处理器中引入，开始它主要用于16位系统。从Intel 386处理器发布开始升级为32位，并且32位指令集一直保持了很久。了解32位系统的都知道32位CPU将内存空间限制到了4G（单一用户模式进程至少是这样）。随着RAM的越来越大，4G限制就成了瓶颈，系统无法使用更大的内存空间。于是2001年Intel发布了64位的IA64架构，它是一个全新的架构，架构设计非常清晰，比老的X86架构要更好。对于软件来说兼容性很重要，但是IA64处理器无法运行X86代码，这样问题就很严重了，已有的软件无法在新的CPU上运行。于是在2003年AMD发布了AMD64架构，它是对X86架构的增量更新，用于添加64位支持。这种架构的X64处理器可以执行X86代码，所以用户可以在X64处理器上运行现有的程序和操作系统。直到今天，X86和X64依旧是个人计算机和笔记本电脑使用CPU的主流。

如下为X64和X86指令，与X86指令相对应，X64指令需要增加额外的前缀字节（REX Prefix）表示使用64位寄存器。由于指针等数据大小翻倍，所以结构体中指针偏移大小也可能会增加。

1
2
3
4
5

// X86指令
0x8B, 0x52, 0x0C, // mov edx, dword ptr [edx+0Ch]

// X64指令
0x48, 0x8B, 0x52, 0x18, // mov rdx, qword ptr [rdx+18h]

一些指令在X86和X64上编码一致，比如短跳转。区分两种指令比较通用的方法是看指令是否携带了REX前缀字节（REX前缀字节用于表示使用64位寄存器或使用64位操作数）。REX前缀字节会覆盖一部分现存X86指令，因此在执行一块代码时需要告知X64处理器按照X86还是X64来解析指令。到底是怎么告知CPU要将代码按照X86解析还是按照X64解析呢？下面看Intel的白皮书给出的关于IA-32e如何区分兼容模式和64位模式。

简介

EXCEPTION_HIJACK，值为0xe0434f4e。意思是CLR线程劫持异常。异常劫持是CLR在挂起线程进行垃圾收集的过程中抛出的。它的抛出是为了帮助停止后恢复执行。它定义在..\clr\src\inc\corexcep.h头文件里，如下：

#define EXCEPTION_HIJACK  0xe0434f4e    // 0xe0000000 | 'COM'+1

详细说明

在现实开发中，经常会出现多个线程同时访问托管堆的情况，或至少会有多个线程同时操作堆中的对象。一个线程引发垃圾回收时，其它线程绝对不能访问任何线程，因为垃圾回收器可能移动这些对象，更改它们的内存位置。CLR想要进行垃圾回收时，会立即挂起执行托管代码中的所有线程，正在执行非托管代码的线程不会挂起。然后，CLR检查每个线程的指令指针，判断线程指向到哪里。接着，指令指针与JIT生成的表进行比较，判断线程正在执行什么代码。

如果线程的指令指针恰好在一个表中标记好的偏移位置，就说明该线程抵达了一个安全点。线程可在安全点安全地挂起，直至垃圾回收结束。如果线程指令指针不在表中标记的偏移位置，则表明该线程不在安全点，CLR也就不会开始垃圾回收。在这种情况下，CLR就会劫持该线程。也就是说，CLR会修改该线程栈，使该线程指向一个CLR内部的一个特殊函数。然后，线程恢复执行。当前的方法执行完后，他就会执行这个特殊函数，这个特殊函数会将该线程安全地挂起。然而，线程有时长时间执行当前所在方法。所以，当线程恢复执行后，大约有250毫秒的时间尝试劫持线程。过了这个时间，CLR会再次挂起线程，并检查该线程的指令指针。如果线程已抵达一个安全点，垃圾回收就可以开始了。但是，如果线程还没有抵达一个安全点，CLR就检查是否调用了另一个方法。如果是，CLR再一次修改线程栈，以便从最近执行的一个方法返回之后劫持线程。然后，CLR恢复线程，进行下一次劫持尝试。所有线程都抵达安全点或被劫持之后，垃圾回收才能使用。垃圾回收完之后，所有线程都会恢复，应用程序继续运行，被劫持的线程返回最初调用它们的方法。

异常结构填充

ExceptionAddress: 762819b2 (KERNELBASE!RaiseException+0x00000062)
ExceptionCode: e0434f4e//异常代码
ExceptionFlags: 00000000
NumberParameters: 0//没有附加参数信息

样例工程

在VS2013里新建一个C#控制台工程，写下如下代码：

usingSystem;usingSystem.Collections.Generic;usingSystem.Linq;usingSystem.Text;usingSystem.Threading;namespaceConsoleApplication1

{classProgram

    {static void Main(string[] args)

        {

            Thread t1= new Thread(newThreadStart(TestMethod));

            t1.Start();

            t1.Join();

        }public static voidTestMethod()

        {while (true)

            {

                StringBuilder sb= new StringBuilder(1024*1024);

                Thread.Sleep(0);

            }

        }

    }



}

当.NET程序有未处理的异常时，您可能会希望关闭出现的调试对话框。下面有两个选项：

1、启用JIT调试的注册表项

对于包含托管代码的应用程序，公共语言运行库将显示类似于JIT附加调试器的对话框。控制此选项的注册表项称为HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\DbgJITDebugLaunchSetting。

• 如果值为0，则通过消息框提示用户。选择包括：“继续”---这将导致堆栈转储和进程终止。“附加调试器”---在这种情况下，运行时生成DbgManagedDebugger注册表项中列出的调试器。如果没有，则返回控件并终止进程。
• 如果值为1，则返回控件。这会导致堆栈转储，然后终止进程。（不再有对话）
• 如果值为2，则生成DbgManagedDebugger注册表项中列出的调试器。

2、如果要禁用“JIT调试”对话框，但仍需要错误对话框

Visual Studio.NET|Tools|Options|Debugging|Just-In-Time 下取消“"Common Language Runtime"”的选择，现在将显示“确定/取消”对话框，而不是“选择调试器”对话框。注意：上面选项1中的注册表项需要为0才能显示对话框。

来个样例

我的符号目录设置是:

用我们在windows下调试必须用到的ntdll.dll模块来讲下windbg加载符号文件的过程。windbg加载符号文件时，会首先根据配置的符号目录信息，在本地符号目录中查找对应的符号文件。一个典型的搜索过程如下:
F:\Debug_Symbol\Symbols32\
F:\Debug_Symbol\Symbols32\pingme.txt
F:\Debug_Symbol\Symbols32\flat.txt
F:\Debug_Symbol\Symbols32\index2.txt
F:\Debug_Symbol\Symbols32\ntdll.pdb\2505F15902821D2C6931BBFF1B941EBF1\ntdll.pdb
F:\Debug_Symbol\Symbols32\ntdll.pdb\2505F15902821D2C6931BBFF1B941EBF1\ntdll.pd_
F:\Debug_Symbol\Symbols32\ntdll.pdb\2505F15902821D2C6931BBFF1B941EBF1\file.ptr

首先解释一下路径中的那一串字母和数字混合的东西是什么玩意儿，这个字符串是编译器根据编译时的时间、版本、程序类型等信息生成的一个类似GUID一样的东西(VC6编译的符号文件其内部编号是编译时间的绝对秒，就是
time
函数返回的32位从1970年1月1日0点开始的秒数，后面加上程序的特征，例如目标机器的类型、程序类型等；VC7.0、7.1、8.0、9.0
编译的符号文件编号是一个
GUID，这可能是为了避免多线程同时编译相同特征的程序引发内部编号冲突)，存储在PE文件的DebugDirecotry数据目录指向的数据中，暂且称之为pdb的索引串，对于每个编译出来的文件而言它是唯一的。同名文件的不同版本，它的这个索引串也不同。

过程详解

下面我来逐一解释下上面看到的这个搜索过程:

1. 调试器先检查符号目录是否存在
2. 检查符号目录下是否存在flat.txt、pingme.txt或index2.txt。这三个文件的存在与否，决定了搜索过程中的一些细节。
   如果存在pingme.txt，说明该目录下存在自动下载的符号文件。那么windbg将按照自动下载时的存放路径来检查符号文件是否存在。若没有pingme.txt，将不会采用这种路径来搜索。具体搜索方式参考第3条。
   如果存在flat.txt(即使同时也存在pingme.txt)，将忽略上面这种采用pdb索引串的快捷搜索方式，只以文件名和文件类型等信息进行搜索。
   如果存在index2.txt,将按照文件名称分组进行搜索。分组方式是：使用符号文件名称的前两个字母最为一级目录，符号文件的名称作为二级目录，符号文件的编号作为三级目录，如此可对大量的文件进行分级索引，避免Symbols 目录下的子目录过多。比如以下路径:
   F:\Debug_Symbol\Symbols32\ke\kernel32.pdb\
   F:\Debug_Symbol\Symbols32\nt\ntdll.pdb\
   F:\Debug_Symbol\Symbols32\nt\ntkrnlpa.pdb\
3. 按pdb索引搜索(要求pingme.txt存在)
   对于windbg自动下载的符号文件，会以"符号目录+符号文件名+pdb索引串+符号文件名的方式"为路径存储符号文件，这样，在下次需要查找该符号时，可以直接从PE文件中取得pdb索引串，然后构造出这样一个路径来快速加载符号文件。这就是搜索路径"F:\Debug_Symbol\Symbols32\ntdll.pdb\2505F15902821D2C6931BBFF1B941EBF1\ntdll.pdb"的由来。当存在pingme.txt时，将优先采用这种方式搜索。当然，自动下载符号的目录一般会自动创建一个pingme.txt的。
4. 检查是否存在压缩的符号文件
   windbg从符号服务器下载的符号文件，有些可能是压缩形式(文件名以_结束，需要用expand.exe解压缩)，所以windbg会检查ntdll.pd_的存在，若存在就会将其解压缩。file.ptr可能也是某种方式的临时文件，暂时我无法完全解释它。
5. 以符号文件名作为文件夹名进行搜索
   如果以上都没有找到，那么就检查符号目录下ntdll.pdb这个文件夹是否存在，注意这里是文件夹。如果该文件夹存在，就会继续查找F:\Debug_Symbol\Symbols32\ntdll.pdb\ntdll.pdb。若文件夹不存在，就会直接在符号目录下查找符号文件ntdll.pdb(注意是文件)。
6. 以目标文件的类型作为分类搜索
   如果仍然没有找到，那么将根据PE文件的类型(dll,exe,sys,ocx等)作为子目录进行查找(安装的符号文件一般是以这种路径形式存放的)。
7. 以目标文件Debug信息中指定的符号路径进行搜索
   对于我们自己编译的驱动，通常是包含了pdb文件的全路径的，随便用一个编辑器打开一个sys文件都可以看到文件中出现的pdb路径信息。
8. 搜索windbg所在路径
9. 到符号服务器查找符号
   如果以上都没有找到的话，也就是说本地符号库中无法找到匹配的符号文件，如果符号设置中允许自动到符号服务器下载符号（比如出现了"SRV*F:\Debug_Symbol\Symbols32*http://msdl.microsoft.com/download/symbols"这样的配置），那么windbg就会根据PE文件的pdb索引串到符号服务器上查找是否有与该pdb索引串匹配的符号文件，若有，就将其下载到本地，若没有，那就是真的没有了，windbg将返回"ERROR: Symbol file could not be found."