Windows Codex Desktop appears to reinstall/start SysmonDrv v13.22; WinDbg points to SysmonDrv.sys BSODs

[Cartmancxx]

Summary

On Windows, Codex Desktop local/PowerShell sessions appear to reinstall or start Sysinternals Sysmon v13.22 (SysmonDrv.sys) after it has been force-uninstalled. The affected machine then repeatedly crashes. Multiple WinDbg analyses of kernel dumps point to SysmonDrv.sys as the crashing module.

This looks safety-critical because it involves an unexpected kernel driver being installed/reinstalled and repeated system crashes.

Environment

• Product: Codex Desktop app on Windows
• Agent mode: Windows native / PowerShell local execution
• OS: Windows desktop host
• Sysmon observed version: 13.22, Sysinternals - www.sysinternals.com
• Sysmon paths observed:
  • C:\Windows\sysmon.exe
  • C:\Windows\SysmonDrv.sys
• Services observed:
  • Sysmon
  • SysmonDrv

Observed behavior

After uninstalling Sysmon with:

C:\Windows\sysmon.exe -u force
sc.exe query SysmonDrv
sc.exe query Sysmon

sc.exe reported both services as not installed (1060). After reboot, before using Codex, the user observed that SysmonDrv was still absent. After resuming/using Codex Desktop conversation/local execution, SysmonDrv and Sysmon appeared again and were running.

The machine repeatedly black-screened/rebooted, and one crash presented as an orange screen. Several crashes happened while Codex local commands were running.

Crash evidence from WinDbg

Multiple dumps were analyzed with WinDbg/CDB. The crashing module/bucket repeatedly pointed to SysmonDrv.sys, not to the user-mode process itself.

Examples:

• Bugcheck 0x50 PAGE_FAULT_IN_NONPAGED_AREA

  • MODULE_NAME: SysmonDrv
  • IMAGE_NAME: SysmonDrv.sys
  • FAILURE_BUCKET_ID: AV_SysmonDrv!unknown_function
  • Stack included SysmonDrv+1321

• Bugcheck 0x13A KERNEL_MODE_HEAP_CORRUPTION

  • MODULE_NAME: SysmonDrv
  • FAILURE_BUCKET_ID: 0x13a_12_SysmonDrv!unknown_function
  • Stack included nt!ExFreePoolWithTag -> SysmonDrv+821d

• Bugcheck 0xC2 BAD_POOL_CALLER

  • MODULE_NAME: SysmonDrv
  • FAILURE_BUCKET_ID: 0xc2_99_SysmonDrv!unknown_function
  • Stack included nt!ExFreePoolWithTag -> SysmonDrv+81fe

More recent dumps after Codex was used again showed:

• PROCESS_NAME: codex.exe, MODULE_NAME: SysmonDrv, IMAGE_NAME: SysmonDrv.sys, bugcheck 0xC2
• PROCESS_NAME: codex.exe, MODULE_NAME: SysmonDrv, bugcheck 0x13A
• PROCESS_NAME: RazerAppEngine, MODULE_NAME: SysmonDrv, bugcheck 0xC2

This suggests the user-mode process being monitored can vary, while the kernel module implicated by the dumps remains SysmonDrv.sys.

Reproduction pattern

1. Force-uninstall Sysmon:

C:\Windows\sysmon.exe -u force
sc.exe query SysmonDrv
sc.exe query Sysmon

2. Confirm both return service-not-installed (1060).
3. Reboot.
4. Before opening/using Codex, confirm SysmonDrv is absent.
5. Open/resume Codex Desktop and continue a local Windows/PowerShell session.
6. Observe Sysmon/SysmonDrv returning and running.
7. System later crashes; WinDbg points to SysmonDrv.sys.

Expected behavior

Codex Desktop should not silently install or reinstall a kernel driver after the user has removed it. If Sysmon is intentionally part of the Windows local execution/sandbox/monitoring implementation, the app should:

• use a current safe version,
• ask for or clearly document elevated driver installation,
• stop reinstalling it after explicit uninstall,
• avoid causing BSODs,
• provide a user-facing way to disable that component or switch execution mode.

Questions for maintainers

1. Does Codex Desktop for Windows intentionally install or depend on Sysinternals Sysmon/SysmonDrv?
2. If yes, why is Sysmon v13.22 being installed, and can this be updated or disabled?
3. Is there a known interaction between Windows-native Codex local execution and SysmonDrv.sys heap/pool corruption bugchecks?
4. What logs should affected users provide privately to diagnose the installer/reinstaller process without publicly exposing minidumps or account data?

Additional notes

A Razer/AMD overclock driver was also investigated because it was noisy in Service Control Manager events, but it was disabled and stopped while Sysmon/SysmonDrv continued to reappear. The crash dumps analyzed so far consistently point to SysmonDrv.sys rather than the Razer/AMD driver.

Minidumps, WinDbg output, and event log extracts can be provided privately if OpenAI maintainers request them.

[Cartmancxx]

Additional impact update from the affected user:

After further mitigation attempts, the machine rebooted/crashed again while Codex was being used for mitigation. The user reports that Codex-related crashes/reboots have now happened many times and caused loss of unsaved work/data.

The user has now switched Codex from Windows-native execution to WSL and restarted, as a temporary workaround. They still need an official answer on:

1. whether Codex Windows native intentionally installs/starts Sysmon/SysmonDrv,
2. how to fully disable that component,
3. whether Windows-native execution can be made safe without SysmonDrv,
4. what private logs/dumps OpenAI wants for diagnosis,
5. whether affected users can receive usage/token/subscription compensation for repeated BSODs and lost work.

Please treat this as more than a normal app crash: the suspected failure path involves a kernel driver (SysmonDrv.sys) and repeated full-system restarts.

[Mahkhmood9]

3 things I suggest

1. (I believe codex-cli or codex-ide should work in ur case) If this works -- and reply back -- so it better can be root-caused back to the codex-desktop(a bit [trickey to debug because ur systeming is crashing])
2. modern windows installation (as much as I dont like to suggest it -- SysmonDrv is a windows thing or a Visual Studio / c++ related thing ? if you are developing )
   2.1 sidenote with windows-11 - it has to do with the microsoft score (unrelated because you are using an very outdated version of SysmonDrv ---- this has importance -- because of the way CODEX DESKTOP is built and also intalled from the MICROSIOFT STORE ) https://learn.microsoft.com/en-us/sysinternals/downloads/microsoft-store
3. If your system is overclocked **its completely natrual for the system to maybe crash - if your cpu spikes to 100% all the sudden --- you may argue -- you can still play games without crashing - but I will argue back that games dont usally take 100% of your cpu ** [I suggest undo all of the overclocking you did] (Wether its settings in the mothersboard-bios or some weird AMD supplied software for overclocking ) (a. go to your motherboard bios [click default settings] b. undo the overclocking and uninstall the AMD software , altenratively updating your motherboard bios should also help [if you bought a good brand - there is always a bios update every 2-4 months which is very good] [but i dont think you are in the lucky side if your are using some unknown brand -- because if you cpu is very modern and the motherboard is outdated weird things can happen because for how long AMD tries to maintained their AM4 sockets -- like off-labled/generic chinese motherboarids ] [that being said if its motherboard you could be using some of the])

I never would have guess, too see the day that linux would have the best hardware support. (but understand its a big deal for hardware people to say for themselves they helped improve the linux kernel -- and the different ways it complie for different systems too btw - what windows-embeded would never could have been --- historically speaking of/ )
but you do mention you do overclock yoursystem ---- when you play video games, and maximize your CPU does it crash?

If codex is the issue, the same should be replicated if you use Codex-cli or codex-ide
but I recomend give it a try, I think using IDE or CLI can fix the issue you are facing --- If Codex Desktop attached to SysmonDrv.sys and
crashes some how ---
your side report back if its the CODEX DESKTOP to use codex on other platforms (the ide extension is really good)
cant ask you for logs - because you say your system fully crashing

i be honest i you can also say , (I used another llm product to run WinDbg, and I didnt had the crash) in theory you could say that too , so maybe there is something with CODEX DESKTOP

https://developers.openai.com/codex/ide
(can be used inside your VSCODE editor)
or
https://developers.openai.com/codex/cli

just to confirm you are not using windows 8 or 8.1 or 7 or something else weird --- we are speaking about windows 10 or 11 (because drivers support can be a bit weird)
(perhaps a "windows server" version )

granted you may have a valid point when it does try to speak to Sysinternals Sysmon

far as I concern maybe WnDbg couldnt deal some some weird logs --- leading the ai model you used to confuse Sysmon which vary based on what prompt you used
(you can use //Sysinternals Suite//)

sysmon is now at version Sysmon v15.2
see - https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

(but maybe its [Windows 10 kernel framework] ) so its not a click on the windows update thing (or blame your AMD drivers) Its a bit weird considering how much I like to credit AMD for how much they improved (if its a hardware issue )

Im not going to tell to try and manual start placing Sysmon v15.2 in the place you put it
also suspect are doing development work maybe with Visual Studio Enterprise or something that made you install WinDbg (because I noticed LLM models like to see whats installed on your ocmputer)

[Cartmancxx]

Thanks for the suggestions. A few clarifications from the affected machine:

1. This does not currently look like a generic CPU/RAM/overclock instability issue.

   Overclocking is a reasonable general thing to check, but the crash evidence does not match a typical unstable CPU/RAM pattern. Multiple kernel dumps showed different bugchecks (0x50, 0x13A, 0xC2), but they repeatedly converged on the same module:

   • MODULE_NAME: SysmonDrv
   • IMAGE_NAME: SysmonDrv.sys
   • stacks such as nt!ExFreePoolWithTag -> SysmonDrv+...

   If this were primarily unstable CPU/RAM/overclocking, I would expect more random failing modules or WHEA/Machine Check evidence. The consistent kernel module attribution is why this issue is focused on SysmonDrv.sys and Codex Desktop Windows-native execution.

2. The Sysmon v13.22 instance does not appear to be my own pre-existing system/Visual Studio component.

   I force-uninstalled Sysmon with C:\Windows\sysmon.exe -u force and confirmed both Sysmon and SysmonDrv were not installed (sc.exe query returned 1060). After reboot, before using Codex, SysmonDrv was still absent. After resuming Codex Desktop / Windows-native local execution, Sysmon and SysmonDrv appeared again and were running.

   That timing is the important part: the old SysmonDrv.sys reappeared after Codex Desktop interaction, not because it was simply sitting on the machine from Visual Studio, WinDbg, or my normal Windows installation.

3. I agree that trying Codex CLI / IDE / WSL is useful as isolation.

   I have already switched Codex Desktop away from Windows-native execution to WSL as a temporary mitigation. If the machine remains stable under WSL/CLI/IDE while Windows-native Codex Desktop reintroduces SysmonDrv, that would further narrow the issue to Codex Desktop's Windows-native execution path.

4. The version question is still relevant, but not as a user-side fix.

   Microsoft Sysmon is currently much newer than v13.22, but manually updating Sysmon is not a proper mitigation if Codex Desktop is the component reinstalling or starting an older driver. The thing I need from maintainers is confirmation of whether Codex Desktop Windows-native mode intentionally installs/starts Sysmon/SysmonDrv, and if so, how to disable it or ensure it uses a safe/current component.

So I am not claiming overclocking can never crash a PC. I am saying the evidence from this incident points elsewhere: repeated crashes attributed by WinDbg to SysmonDrv.sys, plus a reproducible timeline where SysmonDrv returns after Codex Desktop Windows-native usage.

[Cartmancxx]

Additional hardware / OS stability context from the affected user:

This is not an old or unsupported Windows installation, and it is not an obscure/off-brand motherboard or BIOS environment. The system is kept on current Windows updates. The user also reports that this machine is normally stable outside of this Codex Desktop Windows-native/SysmonDrv incident.

I am intentionally not posting a full hardware fingerprint publicly here. Exact CPU/GPU/RAM/BIOS/Windows build information can be provided privately to OpenAI maintainers if needed.

The main point is that the current evidence does not support reducing this to a generic “bad BIOS / unstable overclock / outdated Windows” explanation. The reproducible timeline remains:

1. Sysmon / SysmonDrv force-uninstalled and confirmed absent (1060).
2. Reboot.
3. Before Codex Desktop Windows-native interaction, SysmonDrv remains absent.
4. After Codex Desktop Windows-native/local execution interaction, Sysmon / SysmonDrv reappear.
5. Subsequent crashes are attributed by WinDbg to SysmonDrv.sys.

So hardware/BIOS details can be shared privately, but the public root-cause signal remains the Codex Desktop Windows-native path reintroducing SysmonDrv.sys and the crash dumps repeatedly pointing to that driver.

[Cartmancxx]

Concrete hardware context from the affected user:

• Machine class: Razer 2025 14-inch laptop / Razer Blade 14-class system
• Memory: 64 GB
• Storage: 2 TB SSD
• GPU: NVIDIA GeForce RTX 5070 Laptop GPU configuration
• Windows: kept current with Windows updates

This is a modern OEM laptop configuration, not an unsupported old Windows installation, a generic/off-brand desktop motherboard, or an unusual BIOS environment. The user reports the system is normally stable outside of this Codex Desktop Windows-native / SysmonDrv.sys incident.

Exact BIOS build, Windows build, and driver package versions can still be provided privately if OpenAI maintainers need them, but the high-level hardware context should rule out the earlier suggestion that this is likely due to a generic/unknown motherboard or legacy platform issue.

[Mahkhmood9]

driver package versions can still be provided privately if OpenAI maintainers

c. (fastest) use VS CODE STUDIO and the IDE extention https://developers.openai.com/codex/ide
2. if it doesnt work -> Update to windows 11, you hardware way too new , SysmonDrv 13.22 was a thing before windows 11 was even annouced - and vibe coded in a afternoon (yes i said it)

1. uninstall RazerAppEngine or update it (if its on the latest version , im sure you can uninstall it )

to yur maschine classed theres is bios updates from 3 days ago

[Cartmancxx]

Thanks @Mahkhmood9, appreciate the suggestions.

Current status update from the affected user: after switching Codex Desktop from Windows-native execution to WSL and restarting, the machine has not encountered the crash/reboot issue so far.

That is useful isolation data: WSL appears to be a working temporary workaround on this machine, while the crashes were observed on the Codex Desktop Windows-native/local execution path where Sysmon / SysmonDrv were reintroduced.

However, this still needs an official Codex fix or explanation. Windows-native Codex Desktop should not silently reinstall/start an old SysmonDrv.sys kernel driver after the user has force-uninstalled it, and it should not be possible for that path to repeatedly crash the host system. The WSL workaround helps the user keep working, but it does not resolve the underlying Windows-native/SysmonDrv issue.

[Mahkhmood9]

Thanks @Mahkhmood9, appreciate the suggestions.

Current status update from the affected user: after switching Codex Desktop from Windows-native execution to WSL and restarting, the machine has not encountered the crash/reboot issue so far.

That is useful isolation data: WSL appears to be a working temporary workaround on this machine, while the crashes were observed on the Codex Desktop Windows-native/local execution path where Sysmon / SysmonDrv were reintroduced.

However, this still needs an official Codex fix or explanation. Windows-native Codex Desktop should not silently reinstall/start an old SysmonDrv.sys kernel driver after the user has force-uninstalled it, and it should not be possible for that path to repeatedly crash the host system. The WSL workaround helps the user keep working, but it does not resolve the underlying Windows-native/SysmonDrv issue.

you cant try an text if you even got a temporary fix for your issue - whats happening with your issue is windows/hardware issue -- what do you expect them to do? its not like you provided actual logs and data to back its a codex desktop thing

instead you ignore any attempt for help - and dont provide anything practical - beside poorly written llm written argument

[Cartmancxx]

Thanks for continuing to help. I understand your point, and I do appreciate the suggestions.

One clarification first: I am a Chinese-speaking user, so I use an LLM to help translate and structure my replies in English. That is only to make the technical report clearer and less ambiguous. I am not trying to avoid providing logs or ignore practical troubleshooting suggestions.

My current understanding is not “Codex magically crashes the hardware by itself.” The issue appears more specific: Codex Desktop’s Windows-native/local execution path seems to reinstall or start an old SysmonDrv.sys after I start/resume a conversation. The final crash may be caused by a compatibility bug between that old Sysmon driver and my hardware/driver environment, but the important point is that the driver reappears after Codex Desktop Windows-native usage.

I did also investigate the overclocking angle. During troubleshooting, the AMD/Razer CPU overclocking-related driver/service was disabled/stopped, but the machine still rebooted/crashed afterward. So I do not currently have evidence that CPU overclocking is the primary cause.

Current mitigation result: after switching Codex Desktop from Windows-native execution to WSL and restarting, I have not encountered the crash/reboot issue again so far. That is useful isolation data, but it is still a workaround rather than a fix for the Windows-native path.

Here is the practical evidence summary collected so far:

WinDbg / crash dump summaries:

1) Bugcheck 0x50 PAGE_FAULT_IN_NONPAGED_AREA
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys
   FAILURE_BUCKET_ID: AV_SysmonDrv!unknown_function
   Stack included: SysmonDrv+1321

2) Bugcheck 0x13A KERNEL_MODE_HEAP_CORRUPTION
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys
   FAILURE_BUCKET_ID: 0x13a_12_SysmonDrv!unknown_function
   Stack included: nt!ExFreePoolWithTag -> SysmonDrv+821d

3) Bugcheck 0xC2 BAD_POOL_CALLER
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys
   FAILURE_BUCKET_ID: 0xc2_99_SysmonDrv!unknown_function
   Stack included: nt!ExFreePoolWithTag -> SysmonDrv+81fe

More recent dumps after Codex Desktop was used again:

4) Bugcheck 0xC2
   PROCESS_NAME: codex.exe
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys
   Stack included: nt!ExFreePoolWithTag -> SysmonDrv+...

5) Bugcheck 0x13A
   PROCESS_NAME: codex.exe
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys

6) Bugcheck 0xC2
   PROCESS_NAME: RazerAppEngine
   MODULE_NAME: SysmonDrv
   IMAGE_NAME: SysmonDrv.sys

Sysmon / service timeline summary:

- `C:\Windows\sysmon.exe -u force` was run.
- `sc.exe query SysmonDrv` and `sc.exe query Sysmon` returned 1060 / service not installed.
- After reboot, before using Codex Desktop Windows-native execution, SysmonDrv was still absent.
- After resuming/using Codex Desktop Windows-native/local execution, both services reappeared and were running:

  SERVICE_NAME: SysmonDrv
  TYPE: KERNEL_DRIVER
  STATE: RUNNING

  SERVICE_NAME: Sysmon
  TYPE: WIN32_OWN_PROCESS
  STATE: RUNNING

- The observed Sysmon version was 13.22.
- The observed files were:
  C:\Windows\sysmon.exe
  C:\Windows\SysmonDrv.sys

Overclocking-related check:

- AMDRyzenMasterDriverV29 was checked during troubleshooting.
- It was observed as STOPPED, and later disabled/stopped during mitigation.
- Sysmon/SysmonDrv still reappeared and crashes still occurred afterward.

I can provide full minidumps, .evtx logs, and full WinDbg output privately to OpenAI maintainers if they request them. I do not want to publish full crash dumps publicly because they may contain machine/account-specific information.

I agree that CLI/IDE/WSL are useful isolation paths. I have not moved my main workflow to CLI because much of my current project management and non-coding work is inside the Codex Desktop App. So CLI/IDE can help isolate the issue, but they are not equivalent replacements for fixing the Codex Desktop Windows-native behavior.

[Cartmancxx]

Request for OpenAI maintainers:

The affected user is willing to provide the original Windows event logs, WinDbg outputs, and crash dump files privately to OpenAI for investigation.

Because full minidumps / MEMORY.DMP / .evtx files may contain machine-specific or account-specific data, we do not want to upload them publicly to this GitHub issue. Please provide an official private intake path or confirm the preferred channel for sending:

• original Windows System/Application event logs around the crash times,
• minidumps from C:\Windows\Minidump,
• relevant MEMORY.DMP analysis if needed,
• full WinDbg !analyze -v outputs,
• Service Control Manager events showing Sysmon / SysmonDrv installation/start times,
• sc.exe query before/after outputs,
• SysmonDrv.sys / sysmon.exe version and timestamp evidence,
• mitigation evidence after switching Codex Desktop from Windows-native execution to WSL.

Current high-level evidence already summarized in this issue:

1. Multiple bugchecks (0x50, 0x13A, 0xC2) repeatedly point to SysmonDrv.sys.
2. Sysmon / SysmonDrv were force-uninstalled and confirmed absent (1060).
3. After reboot they remained absent before Codex Desktop Windows-native usage.
4. After Codex Desktop Windows-native/local execution interaction they reappeared and were running.
5. The observed Sysmon version was 13.22, while the current Microsoft Sysmon release is much newer.
6. The AMD/Razer CPU overclocking-related driver/service was stopped/disabled during troubleshooting, but crashes still occurred afterward.
7. After switching Codex Desktop from Windows-native execution to WSL, the crash/reboot issue has not reappeared so far.

The user is requesting official investigation of whether Codex Desktop Windows-native mode intentionally installs/starts Sysmon/SysmonDrv, why this old driver version is involved, how to disable it, and whether affected users can receive usage/token/subscription compensation due to repeated full-system crashes and lost work.

[Mahkhmood9]

Stack included: nt!ExFreePoolWithTag -> SysmonDrv+...

dont consume the two the CLI and IDE are two different products (the IDE aka means the VSCODE EXTENTION )
Do what I told you earlier ,

1. update your bios
2. go to your bios - and use default settings
3. go to the vibe coded AMD drivers app --- and try search for something call "reset settings"
4. if you can , Im sure reinstall with windows 11 would fix the issues due to the nature of how different its installed there

you earlier refused to give me your windows version , which is a bit funny to me ---

anyways - if you can please provide the crash dumps - im sure it can help the openai team to debug (or not?)

second the codex - ide within the visual studio isnt that bad - and honestly I think better --- not that you cant get simular exprience with either of them --- I mean the codex desktop consume , more cpu and is 1.5gb on the ssd (which I dont care but im not a fun of it)

You are not going to do it, because you expect a coding agent, to restart your computing and do it for you - and reset your bios settings, update it extra?

Im sure if you can afford your expensive laptop - you can afford 5 minutes to read something from someone who tries to help you