Last week, I fed some Intel Processor Trace (Intel PT) output from SourcePoint into the ChatGPT LLM, and it successfully parsed and analyzed all the code as Windows ran from the Secure Kernel, into the hypervisor, and out again into the NT Normal Kernel. This week, let’s look at the same from an event trace point of view, using Architectural Event Trace (AET).
As a preamble to this article, you can see the article on using ChatGPT with Intel Processor Trace here: Using ChatGPT on Windows Secure Kernel with Intel Processor Trace. And an introductory article to AET is here: Intel Architectural Event Trace (AET) in action. And a good video of a live demonstration of AET is in my webinar recorded video with the UEFI Forum: UEFI Debug with Intel Architectural Event Trace.
Intel PT and AET are two sides of the same coin: the first captures instruction execution trace, and the latter captures low-level x86 architectural events. Both are very powerful tools for understanding firmware, hypervisor and operating system operation from a systems perspective. Intel PT delivers the explicit path through a particular region of code, and AET displays the bigger-picture system operation of interactions between individual processors, BIOS, OS, device drivers, and peripherals. Both are well suited to do powerful debugging and reverse engineering tasks.
Just as a recap, AET uses the Intel Trace Hub as its trace collector, and the trace data can be routed to the system memory, over the DbC (Debug Class) DCI (Direct Connect Interface) USB cable, or into the MTB (Master Storage Controller Trace Buffer – a small ~8kB buffer that is accessible directly out of system reset). For the purpose of this analysis, we stream AET trace data directly over the DCI/USB interface into the host debug PC running SourcePoint:
AET can capture the following trace events, as can also be seen in the image below:
HW/SW Interrupt
IRET
Exception
RDMSR/WRMSR
Port In/Out
Code breakpoint*
Data breakpoint*
BTM
SMI/NMI/RSM
Monitor/MWAIT
WBINVD
SGX
* AET is implemented in CPU microcode and does not modify CPU behavior at all. The two exception events are Code breakpoints and Data breakpoints: AET allows hardware breakpoints to, instead of halting the processor as breakpoints normally do, to collect the data associated with these as events, without stopping the processor. This is an extremely useful capability for debugging race conditions and other “Heisenbugs”.
One very cool thing about AET is that any attempt to access AET-related registers outside of probe mode (that is, with a JTAG debugger like SourcePoint available) will cause a General Protection fault. So, this is a JTAG-only feature.
So, given that background, let’s dive in. To test out ChatGPT’s analysis capabilities on AET, I booted up my AAEON UP Xtreme i12 Core i7-1270PE board (that has 8 performance threads (p-cores) and 8 efficiency cores (e-cores)), and halted the target on the first e-core (P0) when it was at the Secure Kernel VTL1 entry point (ShvlpVtl1Entry). I set up AET with the following settings, and then booted up to the Windows desktop:
Note: it’s possible to turn on capture for all events, but in some cases it is possible that overflow the DbC handler trace buffer – in which case SourcePoint will log and discard the packet. It’s a performance optimization we need to make. We’ll write more about this later.
Tons of trace comes out of the target as it boots into Windows. In the interest of time, and wondering if I would overflow ChatGPT’s file handling capabilities (more on this later), I simply captured about 40,000 events; about four seconds’ worth of trace. A subset of the output looks something like this:
Or another snipped example strictly in text form as submitted to ChatGPT:
Event: MSR Write: Addr=00000048, Data=0000000000000405 (SPEC_CTRL) -074540824 P15 FFFFF80F37E1BFC6 wrmsr -3.940 sec -074540778 P8 Event: Port Out: Port=00B2, Data=000000A0 -3.940 sec -074540768 P3 Event: Exception #0 (0x00): Divide Error -3.940 sec Event: System Management Interrupt -074540758 P15 FFFFF80F37EF1DF1 sete bpl -3.940 sec -074540748 P10 Event: System Management Interrupt -3.940 sec -074540718 P2 Event: System Management Interrupt -3.940 sec -074540708 P7 Event: System Management Interrupt -3.940 sec Event: System Management Interrupt -074540698 P12 FFFFF802E792857F mov eax,[r14+10] -3.940 sec -074540688 P9 Event: System Management Interrupt -3.940 sec -074540678 P1 Event: System Management Interrupt -3.940 sec -074540668 P0 Event: System Management Interrupt -3.940 sec -074540648 P5 Event: System Management Interrupt -3.940 sec -074540618 P6 Event: System Management Interrupt -3.940 sec -074540598 P4 Event: System Management Interrupt -3.940 sec -074540588 P14 Event: System Management Interrupt -3.940 sec -074540568 P13 Event: System Management Interrupt -3.940 sec -074540558 P11 Event: System Management Interrupt -3.940 sec -074540328 P8 Event: System Management Interrupt -3.940 sec -074540239 P3 Event: System Management Interrupt -3.940 sec -074540211 P13 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540201 P2 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540191 P7 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540181 P0 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540171 P12 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540151 P1 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540141 P5 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540091 P6 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540081 P4 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540071 P10 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540061 P9 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074540051 P15 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074539941 P11 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074539861 P14 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec -074539681 P13 Event: MSR Read: Addr=C0000080, Data=0000000000000000 (EFER) -3.940 sec -074539651 P12 Event: MSR Read: Addr=C0000080, Data=0000000000000000 (EFER) -3.940 sec -074539591 P2 Event: MSR Read: Addr=C0000080, Data=0000000000000000 (EFER) -3.940 sec -074539521 P0 Event: MSR Read: Addr=C0000080, Data=0000000000000000 (EFER) -3.940 sec -074539511 P7 Event: MSR Read: Addr=C0000080, Data=0000000000000000 (EFER) -3.940 sec -074539491 P10 Event: MSR Read: Addr=C0000080, Data=0000000000000000 (EFER) -3.940 sec -074539471 P3 Event: MSR Read: Addr=000001A0, Data=0000000000850089 (MISC_ENAB) -3.940 sec
You can see that there’s a lot of cool things going on!
And here’s part of the console output of ChatGPT when I fed some of the events into ChatGPT for analysis:
CHATGPT CONSOLE:
Me: Analyze this Intel Architectural Event Trace and tell me what the events are and what the code is doing:
Excellent — you’ve uploaded the Intel Architectural Event Trace (AET).
What I’ll do now is the following:
- Unpack and parse the trace data.
- Decode the events — this means I’ll map the AET events to understandable categories like:
- Branches
- Interrupts
- Exceptions
- Speculative flows
- Memory accesses (if recorded)
- Microcode assists, VM exits, etc.
- Reconstruct the flow of execution:
- Try to create a logical timeline of what the code was doing.
- Speculate (safely) about purpose: is it initialization, context switch, kernel transition, etc.
- Detect anomalies or interesting patterns:
- Speculative execution quirks
- Interrupt storms
- Shadow stack usage (CET correlation, if data allows)
- Hypervisor or Secure Kernel transitions (especially since you mentioned Secure Kernel — very relevant!)
- Exportable formats (optionally):
- Call graph
- Event sequence
- Summary report
Let me start by unpacking and parsing the contents of your trace file. I’ll begin the analysis right away.
The archive contains a single file:
ADL 7-12-68 AET from Secure Kernel on P0 up to Windows desktop.txt
Perfect — this looks like a raw or processed Architectural Event Trace in text format.
Next, I’ll load this file, parse its contents, and start decoding the events to understand:
- What transitions happened (Secure Kernel to normal desktop)
- What kind of architectural events are logged
- If there are any noteworthy control flow behaviors
Let me process the contents of this file and start mapping out the events.
Here’s what I see in your AET trace so far:
Structure of the trace:
- Each line represents an event.
- Timestamps are negative deltas (counting backwards in time from capture point).
- Logical processors (e.g., P0, P15) are labeled.
- Events include:
- MSR Writes: e.g., MSR Write: Addr=00000048, Data=0000000000000405 (SPEC_CTRL)
- MSR Reads: Addr=000001A0 (MISC_ENAB), Addr=C0000080 (EFER)
- Port I/O: e.g., Port Out: Port=00B2, Data=000000A0
- Exceptions: e.g., Exception #0 (0x00): Divide Error
- System Management Interrupt (SMI) events — interesting!
- Instruction flow: e.g., sete bpl, mov eax, [r14+10]
Immediate observations:
✅ SMI Storm: Multiple “System Management Interrupt” (SMI) events across all cores.
✅ MSR Reads/Writes:
- SPEC_CTRL: Control of speculative execution (mitigation for Spectre-class attacks).
- EFER: Extended Feature Enable Register (controls Long mode, NX bit, etc.).
- MISC_ENAB: General-purpose MSR enabling various processor features.
✅ Exception captured: Divide error (#DE).
✅ Instruction execution trace snippets — meaning we might be able to reconstruct partial control flow.
What this suggests so far:
- The trace is from a very early stage, potentially firmware or hypervisor or Secure Kernel init.
- The storm of SMI events suggests possible firmware/BIOS level management or system management mode (SMM) involvement.
- MSR manipulations and SPEC_CTRL use are typical of system/secure context transitions or bootstrapping secure environments.
- We are transitioning from Secure Kernel up to normal desktop, just as your file name suggested.
Next step:
I will now parse the full log, categorize the events, and try to reconstruct:
- Event flow
- Processor role (Secure Kernel / Hypervisor / OS transition)
- Any anomalies or performance insights
- Instruction flow (pseudo call flow or control graph)
Let’s do that! I’ll process and categorize all events properly.
Here’s a solid first categorization of your trace:
| Event Category | Count |
| 📝 Instructions | 155,394 — majority! |
| 🧩 MSR Writes | 116,654 — very high (speculative control / system setup) |
| 📖 MSR Reads | 63,460 |
| 🔌 Port Output | 182 |
| ⚠️ Exceptions (mostly #DE) | 13,075 |
| 🧭 System Management Interrupt (SMI) | 16 — important for firmware/security analysis |
| 🧩 Other (misc uncategorized lines) | 56,839 — likely additional control/status events, I’ll drill into these too |
What this tells us:
- 🔥 High volume of instruction flow captured.
- We can reconstruct segments of pseudo-C flow from this.
- 🧩 Very high MSR activity, especially SPEC_CTRL, EFER, MISC_ENAB.
- System is actively configuring processor features — likely during Secure Kernel transition.
- ⚠️ Thousands of exceptions, mostly divide errors (#DE).
- Some systems generate artificial exceptions for feature probing or virtualization.
- 🧭 SMI count: 16, not super high, but each one matters. We’ll analyze their timings and relevance.
- ✅ Miscellaneous “other” lines — includes timing metadata and some unparsed events. I’ll look deeper.
Next, let’s do two things:
- Analyze MSR accesses — to understand what registers are touched and why.
- Reconstruct the instruction flow, aiming to recreate logical operations (pseudo C).
This will help us build a clear story of what this trace is showing, from Secure Kernel bootstrapping to Windows desktop.
I’ll start by analyzing MSR access patterns!
Here’s what your MSR access patterns reveal — and this is very interesting:
📝 Top MSR Writes
| MSR Address | Count | Known Usage |
| 00000048 | 26,034 | IA32_SPEC_CTRL — Speculative execution controls (Spectre mitigations). |
| 0000080B | 21,011 | IA32_X2APIC_LVT_THERMAL or related interrupt vector. |
| C0000102 | 15,905 | SYSCALL Target — IA32_LSTAR (64-bit syscall entry point). |
| C0000082 | 14,507 | IA32_LSTAR — syscall target address. |
| C0000103 | 14,332 | IA32_CSTAR — syscall target (compatibility mode). |
| 00000830 | 7,186 | Possibly Performance monitoring or APIC settings. |
| 00000049 | 6,886 | Possibly SPEC_CTRL shadow register. |
| 00000838 | 4,517 | Possible thermal or interrupt configuration. |
| C0000100 | 1,352 | IA32_STAR — Segment selectors for syscall/sysret. |
| 0000083F | 692 | Possibly debug or power management. |
📖 Top MSR Reads
| MSR Address | Count | Known Usage |
| C0000102 | 26,542 | IA32_LSTAR — syscall entry point. |
| 00000048 | 20,284 | IA32_SPEC_CTRL — reading speculative control state. |
| 000000E7 | 6,298 | DEBUGCTL MSR — debug control register. |
| 000000E8 | 6,177 | Possibly Patrol Scrub Control or model-specific. |
| 000017D2 | 2,512 | Model-specific or thermal/power MSR. |
| Others | < hundreds | Less frequent, likely incidental. |
🔍 What this means:
- 🚨 Heavy configuration of speculative execution controls (SPEC_CTRL).
- ⚙️ Setting up syscall entry points (LSTAR, STAR, CSTAR) — this aligns perfectly with OS kernel or Secure Kernel transitioning to user mode.
- 🔥 Intense access to debug and thermal control MSRs — likely part of platform firmware or hypervisor/secure boot preparation.
- 🛡️ Secure Kernel setting up syscall and exception handling environment.
This paints a picture of a system that is:
- Preparing syscall infrastructure
- Managing speculative execution security
- Possibly virtualized or monitored (DebugCtl is actively read)
- Finalizing the transition from the Secure Kernel environment into Windows normal execution.
Next Step:
I will now reconstruct the instruction flow.
This will give us pseudo-code level insight into what the processors were executing in this trace — combined with these MSR writes, it should give a clear understanding of the Secure Kernel to Desktop transition.
Let’s go! 🚀
Now this is very revealing.
🔍 Top Instructions Executed in Trace
| Instruction | Count | Meaning |
| wrmsr | 101,668 | 🔧 Write to Model Specific Register (MSR) — very intense system setup. |
| rdmsr | 37,504 | 📖 Read from MSR — querying system state repeatedly. |
| iretq | 9,155 | 🧩 Return from interrupt (long mode). Indicates interrupt-heavy flow. |
| jmp | 5,551 | ➡️ Unconditional jump — flow control. |
| cmp | 564 | 🔍 Compare operation — typical for decision making. |
| add | 350 | ➕ Arithmetic (setup calculations). |
| mov | 232 | 📝 Data movement. Surprisingly low, implies more config than data ops. |
| or | 78 | 🧩 Bitwise operations, likely flag setups. |
| test | 40 | 🔍 Conditional flag setting. |
| retn | 39 | ⏎ Function return (near). |
| sal, adc, xor, shr, sub, and | ~30 each | Bit operations — typical of low-level config. |
| cli | 6 | 🚫 Disable interrupts — critical sections. |
| in | 19 | 🔌 Port input. |
| lea | 18 | 🧮 Effective address calculation. |
| movzx | 6 | 📏 Zero-extend move — data handling. |
🧩 Interpretation:
- Overwhelming use of wrmsr and rdmsr tells us this is early platform setup or security-critical transition.
It confirms low-level control setup, like:- Configuring control registers
- Setting up interrupt/exception handlers
- Virtualization and speculative execution mitigations
- High iretq count: heavy interrupt-driven flow.
Combined with exception analysis, this looks like:- Timer interrupts
- Possibly virtualization exceptions
- Secure Kernel or hypervisor dispatch
- Moderate jmp count: typical of low-level control flow (setup loops, dispatch tables).
- Arithmetic and logic ops (cmp, add, etc.) are present but not dominant — expected in a config-heavy sequence.
Summary so far:
✅ System is in platform setup / transition phase, configuring MSRs heavily.
✅ Interrupt and exception handling is actively being configured and used (iretq, cmp, jmp).
✅ Flow control is tight and low-level, not application code — this is definitely OS or hypervisor layer code.
✅ Good sign: No signs of abnormal speculative abuse or unexpected instruction mixes yet.
ChatGPT isn’t perfect, but the accuracy of the results as they stand is outstanding. And I stopped my investigation only partway through the “Advanced Forensics” offering that ChatGPT made. I think with more focused prompt engineering I can certainly glean much more about what’s going on.
And the next article will feed both Intel PT and AET simultaneously into ChatGPT for analysis. In SourcePoint, instruction trace and event trace share a common timestamp as generated within the Intel silicon; so it is possible to zero in on specific events, and then look at all of the code that leads up to it. Pretty amazing – that will be a fun article.
If you have 40 minutes or so and want some SourcePoint 101 basic training, I recommend my webinar recording that you can watch here: Debug of Hyper-V, Secure Kernel, VBS Enclaves, Defender, and other secrets.
