. NET exception mechanisms

Introduction to Exception mechanisms

When the CPU runs to some illegal instructions, such as a 0 error, access memory page failure and other instructions, the CPU generates a hardware exception, different exceptions have a fixed exception code as identifiers, the exception is generated after the CPU temporarily cannot continue to execute subsequent instructions-because the subsequent instructions may also be invalid. Of course, the whole computer system can not be so, so the CPU built an exception processing table-this exception processing table only run in kernel mode code to access, the operating system at the start of the initialization of the exception processing table, for each exception to register an exception handler, so this table looks like:

0xC0000005

Accessviolationexceptionhandler ()

......

0x80000003

Launchornotifydebugger ()

After the CPU generates an exception, the exception handler is searched for the corresponding exception handler in the exception-handling table, and the exception handler is called to perform the appropriate processing before proceeding with other code.

In addition to handling CPU-customized hardware exceptions, there are some empty table entries in the Exception handling table so that the operating system can implement software exceptions by adding custom exception codes and corresponding exception handlers. In the Windows operating system, programs can trigger software exceptions by calling Win32 's RaiseException function. As a result, exceptions in C + + and. NET are actually implemented by calling RaiseException, but the exception handling table is not large and only holds no more than 256 exception handler information, so Windows defines only a few common exception codes to represent C + + and. NET exceptions.

0xE06D7363

Represents a C + + exception

0xe0434f4d

Represents the CLR (or. NET) exception

For CPUs, hardware exceptions, software exceptions, C + + exceptions, and. NET exceptions are triggered and processed in the same way, which is called Structured exception handling (SEH) in Windows.

Exception handling

1. When there is an exception in the program after the occurrence;

2. Seh begins by backtracking the stack contents, looking for an exception handling block within the program (the catch block that we usually know), and if an exception handler is found to handle the exception, Windows releases the stack underneath the function where the exception handler block is located, and execute the code inside the exception handling block.

3. If Windows does not find any exception processing block to handle this exception, that is, to the program entrance (main) function does not find a suitable exception processing block, Windows will use its own exception processing block to handle the exception;

4. Windows comes with an exception block that checks to see if your program has a debugger attached, and if so, Windows interrupts the program and gives control to the debugger.

5. If no debugger is attached to your program, Windows starts registering the default autopsy debugger in the registry, in general, the default debugger for Windows is Dr Watson, and this debugger's job is to pop up the famous "Debug or Terminate" dialog box (or " Do you want to send error reports to Microsoft? dialog box):

In the above process step, the first step through raiseexception to trigger the exception, Windows will first check whether your program is being debugged, if there is a debugging is attached to your program, Windows to debug send a debug message, Notifies the debugger that an exception occurred, asking the debugger to interrupt the program, and by default the debugger ignores the message-because our pure debugger always believes that programmers can write good code. This step is referred to as the first opportunity in the debug terminology-first chance-to observe the environment that triggered the exception at the scene where the exception occurred.

The 3rd step after the operating system to handle this exception, in the debug term called the Second Chance (Second chance), because this time the program is actually dead (there will be no life activities)-not critically ill, So this time, even if you attach the debugger to check the environment that triggered the anomaly, just as the coroner was examining the cause of the abnormal death of the person-postmortem commissioning.

Set debugger do not ignore first chance exception

In the process of development, we certainly want to check the code error (bug) when the program is critically ill (first chance exception), so if there are some inexplicable bugs in the program, when debugging the program, it is best to tell the debugger not to ignore the first chance exception. Because if the exception is caught in the code inside the program, it is likely to cause us to ignore important clues.

In WinDbg, use the following command to tell the debugger not to ignore the first chance exception:

Sxe Exception Code

Note there is a space behind sxe, for example, in debugging. NET program, you can use the command sxe 0xe0434f4d to make the debugger break the execution of the program before the catch block executes.

You can use the command

Sxd Exception Code

To enable the ability to ignore first chance exceptions.

. NET exception mechanisms