简介

sx*命令控制调试器在正在调试的应用程序中发生异常或发生某些事件时采取的操作。

使用形式

sx

sx{e|d|i|n} [-c "Cmd1"] [-c2 "Cmd2"] [-h] {Exception|Event|*}

sx- [-c "Cmd1"] [-c2 "Cmd2"] {Exception|Event|*}

sxr

参数

• -c " Cmd1 "
  指定在发生异常或事件时执行的命令。 当处理此异常的第一次机会发生时，无论此异常是否中断调试器，都将执行此命令。 必须将Cmd1字符串用引号引起来。 此字符串可以包含用分号分隔的多个命令。 -C 和带引号的命令字符串之间的空格是可选的。
• -c2 " Cmd2 "
  指定在发生异常或事件并且在第一次机会未处理时执行的命令。 当第二次处理此异常时，会执行此命令，无论此异常是否中断调试器。 必须将Cmd2字符串用引号引起来。 此字符串可以包含用分号分隔的多个命令。 -C2 和带引号的命令字符串之间的空格是可选的。
• -h
  更改指定事件的处理状态，而不是其中断状态。 如果事件为cc、 hc、 bpec或ssec，则无需使用 -h选项。
• Exception
  以当前基数指定命令作用于的异常号。
• Event
  指定命令所作用的事件。这些事件用简短的缩写来表示。
• *
  影响所有未以其他方式显式命名为sx的异常。

支持环境

说明

sx命令显示当前进程的异常列表和所有非异常事件的列表，并显示每个异常和事件的调试器的默认行为。SXE、SXD、SXN和SXI命令控制每个异常和事件的调试器设置。sxr命令将所有异常和事件筛选器状态重置为默认设置。命令将被清除，中断和继续选项将重置为其默认设置，依此类推。sx-命令不会更改指定异常或事件的处理状态或中断状态。如果希望更改与特定事件关联的第一次机会命令或第二次机会命令，但不希望更改任何其他命令，则可以使用此命令。如果包含-h选项（或者如果指定了CC、HC、BPEC或SSEC事件），则SXE、SXD、SXN和SXI命令控制异常或事件的处理状态。在所有其他情况下，这些命令控制异常或事件的中断状态。
设置中断状态时，这些命令具有以下效果：

设置处理状态时，这些命令具有以下效果：

可以结合使用 -h选项和异常，而不是事件。 将此选项与ch、 bpe或sse一起使用将分别设置hc、 bpec或ssec的处理状态。 如果对任何其他事件使用-h 选项，则该选项不起作用。将 -c或 -c2选项与hc、 bpec或ssec一起使用时，会将指定的命令分别与ch、 bpe或sse关联。

在下面的示例中， sxe命令用于将访问冲突事件的中断状态设置为在第一次机会时中断，并设置将在该点执行到r eax的第一条命令。 然后使用sx命令将第一条命令更改为r ebx，而无需更改处理状态。 最后，显示sx输出的一部分，指示访问冲突事件的当前设置：

0:000> sxe -c "r eax" av

0:000> sx- -c "r ebx" av

0:000> sx
 av - Access violation - break - not handled
       Command: "r ebx"

SOS.DLL、SOSEX.DLL这两个就是用来对.NET程序在Windows调试工具中起到翻译作用的调试器扩展。简单讲就是，这两个组件是.NET项目组专门开发出来用来对.NET应用程序进行方便调试用的，当然不用这两个扩展也能调试.NET程序，只不过就会很困难，会被很多细节束缚住。有了这个调试扩展之后，我们就可以让原生Windows调试器正确的翻译出.NET相关概念。

所有对.NET程序发起的调试会话都要经过.NET调试扩展组件进行翻译才行，也就是要使用.NET调试扩展的调试命令来调试.NET程序。上图中，我们如果要想调试.NET程序就需要将.NET调试扩展组件加载到Windows调试工具中去，然后才能方便在Windows调试工具中使用。

还有就是.NET  DAC概念。其实.NET DAC也就是.NET Data Access .NET数据访问层，这个是专门用来提供给SOS.DLL\SOSEXDLL或者其他调试扩展包使用的，所有的调试扩展组件必须通过这个DAC才能访问到.NET运行时的数据，所以在初次使用SOS的时候会经常碰见加载错误的mscordacwks.dll文件，此文件就是DAC的物理文件。

这个文件和SOS扩展文件一样，都有这不同的版本，当加载不同类型的.NET程序时会使用到不同版本的mscordacwks.dll文件，当然大部分情况下此文件时自动加载的，只有出现你分析的文件与生成调试文件的环境不一致时才会出现头疼的问题。

 当你知道这个组件是工作于此位置时，当出现跟它相关的错误提示时你就不需要担心了，无非就是文件加载的位置或者版本不匹配而已。

SOS扩展也是可以和VisualStudio进行集成的，这样真的方便了我们调试一些性能要求比较高的程序，当程序运行一段时间后我们用VS附加到进程，然后查看一些重要的对象数据，但是此时我们看不到.NET运行时的一些数据，比如：对象的代龄，托管堆的大小，线程池的任务等。通过集成SOS扩展会让我们对程序的运行时有了一个更加方便的跟踪。

首先对.net工程做如下设置

 设置断点，然后在”即时窗口“（调试->窗口->即时）中加载扩展SOS.DLL。

这样的便利性大大提高我们在调试程序内存方面、线程方面的好处，我们可以适当的做压力测试，然后Attach process，执行SOS扩展命名来查看内存问题，当需要调试程序逻辑时在单步调式C#代码，一举两得。

简介

STATUS_FATAL_USER_CALLBACK_EXCEPTION，值为0xc000041d。代表的意思是"回调期间遇到未处理的异常"。它定义在 ntstatus.h头文件里，如下：

//
// MessageId: STATUS_FATAL_USER_CALLBACK_EXCEPTION
//
// MessageText:
//
// An unhandled exception was encountered during a user callback.
//
#define STATUS_FATAL_USER_CALLBACK_EXCEPTION ((NTSTATUS)0xC000041DL)

触发条件

当在Windows系统调用的回调方法里发生了任何异常都会触发此异常。

异常结构填充

ExceptionAddress: 74bd4f69
ExceptionCode: c000041d//错误代码
ExceptionFlags: 00000001
NumberParameters: 0//附加参数个数，根据经验来看，vc++编译出来的应用发生了此异常一般都是0

说明

当我们遇到此异常时，一定要深挖背后的异常。

为了说明这个过程，我们必须写一个示例程序，如下：

#include "stdafx.h"#include<tchar.h>#include<stdio.h>#include<Windows.h>

#pragma comment(lib, "user32")WNDPROC oldproc=NULL;



LRESULT CALLBACK newproc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)

{throw 0;returnoldproc(hwnd, uMsg, wParam, lParam);

}int _tmain(int argc, TCHAR *argv[])

{

    HWND hWnd= CreateWindowEx(0, TEXT("STATIC"), TEXT("Name"),

        WS_OVERLAPPEDWINDOW|WS_VISIBLE,

        CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,

        NULL, NULL, NULL, NULL);

    oldproc=(WNDPROC)SetWindowLongPtr(hWnd, GWLP_WNDPROC, (LONG_PTR)newproc);

    

        UpdateWindow(hWnd);



    

        system("pause");

}