WinDBG命令

在断点上打log, 然后继续执行.
bp 10843770 "dd @esp+4 L 4; g"

设置条件断点
bp 10843770 ".if (poi(@esp+4)=0x00110214) {} .else {gc}"
bp 10843770 ".if (poi(@esp+4)=0x10204) {.if (poi(@esp+8)=0x7) {} .else {gc} } .else {gc}"

从内核一直调试到用户
http://www.codeproject.com/Articles/7913/Debug-Tutorial-Part-6-Navigating-The-Kernel-Debugg

During kernel-mode debugging, you can set the process context by using the .process (Set Process Context) command. Use this command to select which processs page directory is used to interpret virtual addresses. After you set the process context, you can use this context in any command that takes addresses. You can even set breakpoints at this address. By including a /i option in the .process command to specify invasive debugging, you can also use the kernel debugger to set breakpoints in user space.

You can also set user-mode breakpoints from the kernel debugger by using a process-specific breakpoint on a kernel-space function. Set strategic breakpoints and wait for the appropriate context to come up.

With WinDBG, another thing you can do is use !bpid to have the kernel debugger break into the context of the process you e interested in and then you can set your breakpoints in the user-mode code (after running .reload to reload your symbols).

For example, setting a breakpoint in CreateFileW in a process:

0: kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
....
PROCESS 861c9d90 SessionId: 1 Cid: 0f10 Peb: 7ffd3000 ParentCid: 0b48
DirBase: 0174e2a0 ObjectTable: 96f14eb0 HandleCount: 5.
Image: testapp.exe
1: kd> .process /r /p 861c9d90
Implicit process is now 861c9d90
..cache forcedecodeuser done
Loading User Symbols

Ubuntu上build insight

insight-6.8-1
1. sudo apt-get install libx11-dev
2. sudo apt-get install libncurses5-dev
3. tar -xjvf insight-6.8-1.tar.bz2
4. cd insight-6.8-1/
5. ./configure (need do configure first)
5. ./configure –disable-werror
6. make
7. sudo make install

解决电话加锁

am startservice -a com.fd.settings -d content://device/unlock -n com.futuredial.FDSettingsService/.FDSettingsService

adb shell am start -n com.futuredial.fdbox721/.fdbox721Activity

.net 4.0 新的非托管异常处理机制.

在.NET 4.0之后，CLR将会区别出一些异常（都是SEH异常），将这些异常标识为破坏性异常（Corrupted State Exception）。针对这些异常，CLR的catch块不会捕捉这些异常，即使你用类似下面的代码：
try
{
TestMethod();
}
catch (Exception e)
{
Console.WriteLine("Catching exception: {0}", e);
}
也没有办法捕捉到这些异常。之所以要这样设计，在MSDN的文章Handling Corrupted State Exceptions里已经提到了。即，有一些支持插件的程序，例如Visual Studio或者SQL Server，它们支持调用托管代码编写成的插件，但是它们自己本身有很多代码是由非托管的C++写成的。由于插件经常会调用到非托管的API，而很多时间，这些插件的代码根本就不知道如何处理非托管的API抛出来的SEH异常。在4.0以前，因为SEH异常被转换成了跟普通.NET异常相同的异常，这样程序员只要用catch ( Exception e)的模式就可以捕捉到所有的异常。这样处理的问题是，由于SEH异常通常都不是托管代码抛出的，托管代码根本就不知道SHE异常被扔出来的原因，简单的catch ( Exception e)处理使得整个程序会处于一个非常不稳定的状态，使得前面被忽略的问题在后面以更严重的方式出现 — 例如保存被破坏的数据。这样，看起来使用catch ( Exception e)处理所有的异常的方法很简单，但实际上让程序员或者用户在问题延后发生时，分析起来需要花费更多的精力。

因此在4.0以后，大部分SHE（我怀疑是所有）异常都被标识成破坏性异常，在.NET里，默认情况下CLR不会捕捉它们，而是任由操作系统来处理—即关闭程序，并打开一个错误对话框通知用户。为了保证兼容性，在4.0以前编译的程序，例如在2.0、3.0和3.5编译的程序，依然采用的是老的策略—即.NET会同时捕捉.NET异常和SHE异常。而在4.0下面编译的程序才会使用新的策略，这也是在文章的开头，我的朋友所碰到的问题。你可以在.NET 4.0下面编译下面的程序，体验一下这个新变化：

Program.cs:
using System; using System.Runtime.InteropServices; namespace ConsoleApplication1 { class Program { [DllImport("Ref.dll")] private extern static void TestMethod(); static void Main(string[] args) { try { TestMethod(); } catch (Exception e) { Console.WriteLine("Catching exception: {0}", e); } } } }

Ref.cpp:
#include "stdafx.h" extern "C" __declspec(dllexport) void TestMethod() { int *p = NULL; // 会导致.NET抛出一个AccessViolation异常 *p = 10; }

上面的代码里，Program.cs使用P/Invoke技术调用了Ref.dll文件里的TestMethod，但是TestMethod尝试给一个空指针赋值，导致一个AccessViolation异常。如果你在2.0下面编译program.cs，并执行的话，这个AccessViolation异常会被catch(Exception e)捕捉到，而如果你在4.0下面编译并执行的话，你会发现catch (Exception e)是不能捕捉到这个异常的。

然而并不是所有人都想要这个新的异常机制，如果你的程序是在4.0下面编译并运行，而你又想在.NET程序里捕捉到SHE异常的话，有两个方案可以尝试：
1. 在托管程序的.config文件里，启用legacyCorruptedStateExceptionsPolicy这个属性，即简化的.config文件类似下面的文件：

App.config:


　
　
　




　
　
　




这个设置告诉CLR 4.0，整个.NET程序都要使用老的异常捕捉机制。

2. 在需要捕捉破坏性异常的函数外面加一个HandleProcessCorruptedStateExceptions属性，这个属性只控制一个函数，对托管程序的其他函数没有影响，例如：
[HandleProcessCorruptedStateExceptions] static void Main(string[] args) { try { TestMethod(); } catch (Exception e) { Console.WriteLine("Catching exception: {0}", e); } }