CPU section shows state of CPU when exception was raised. This section can be disabled in options.

Notes:

•	CPU section is automatically disabled for reporting leaks;

•	Capturing CPU state requires installing of low-level hooks.

CPU section contains 3 parts:

Registers

2.	Stack dump

3.	Memory dump

Registers

Registers block contains list of CPU general-purpose registers (EAX-EDX or RAX-R15), including two index registers (ESI-EDI or RSI-RDI) and two stack pointer registers (ESP-EBP or RSP-RBP).

EIP/RIP register shows current instruction pointer. This is exact instruction which raised exception. It will be some instruction inside Kernel32.RaiseException function for software exceptions. It will be any other CPU instruction for hardware exceptions.

FLG value shows content of EFLAGS/RFLAGS service register.

EXP and STK values shows used addresses for exception address and stack. See section below on explanation.

Stack dump

Stack dump block shows dump of memory used by CPU stack. Left column shows addresses, right column shows data stored in stack. Stack is taken from STK position.

Memory dump

Memory dump block shows dump of memory starting from EXP address. Usually this is code section, which is represented in a human-readable form inside Assembler section.

Real and logical exception address

Hardware exceptions (such as access violation or divide by zero) ara always raised by failed instruction. Thus, exception address for hardware exception points to failed instruction. For example:

var
  P: PInteger;
  E: Extended;
begin
  P := nil;
  P^ := 0;    // <- access violation exception here

  E := 0;
  E := 5 / E; // <- division by zero exception here
end;

Both exceptions in the above code will have unique exception address pointing to failed CPU instruction. Thus, you can easily identify failed code for hardware exception.

On the other hand, any software exception is raised from a single place: Kernel32.RaiseException function. This means that all software exceptions will use the same address, which makes it quite useless. Consider the following code:

Read(F, Data);
if IOResult <> 0 then
raise EUnableToReadFile.Create('There was an error reading file');
if Data = 0 then
raise EInvalidStorageData.Create('File is corrupted, invalid data found');

This code raises two software exceptions. Both exceptions will be raised by the same Kernel32.RaiseException function (which is called by Delphi's "raise" keyword). This makes exception address useless because it does not point to failed code.

For this reason: EurekaLog uses logical exception address which is indicated by EXP value above and also listed as exception address in General section. Logical exception address is equal to real exception address for all hardware exceptions. However, this address points to appropriate "raise" construction for all software exceptions. This makes it behave similar to hardware exceptions - that is, now exception address always point to failed instruction.

The similar ideas can be applied to stack. STK value indicate stack pointer value for exception which is normally would be ESP/RSP register, but it can be altered for software exceptions to exclude calls of service routines (that is "raise", RaiseException, stack collection routines, etc.).