[SOLVED] Bugcheck 0x133 crashes started last night on 2 week old system.

S

Schneider

Member
Joined
Jan 26, 2025
Posts
12
System crash while idle last evening, bugcheck was: 0x00000133. Updated AMD chipset driver. Crashed again middle of the night, same bugcheck (might have been running backup programs at the time). No crashes previous to this.

2 week old computer build reusing some parts

Windows 11 24H2, Original Install, Retail
MB, CPU, Ram, boot NVME ~2 weeks old. Powersupply ~ 3 months old, video card ~ 2 years old
OS installation about 2 weeks ago, has not been reinstalled
AMD Ryzen™ 9 9950X 16-Core, 32-Thread Unlocked Desktop Processor
CORSAIR Vengeance 96GB (2 x 48GB) 288-Pin PC RAM DDR5 6000 (PC5 48000) Desktop Memory Model CMK96GX5M2B6000Z30
ASUS GeForce RTX 4070Ti 12GB
ASUS ProArt X870E-CREATOR WiFi AMD AM5 X870E ATX Motherboard
Super Flower Leadex VII XG 1000W 80+ Gold
Driver verifier not installed
Bitdefender
No proxy etc
No disk image tools
No overclocking, memory speed set to CPU default 5600

Note: system has 3 older WD 4TB SSDs plus 2 new Samsung Pro 990 NVME plus and a newer 8TB WD HDD. 2 of 3 monitors new as of 3 days ago.

System is for Lightroom and Photoshop, not gaming.

http://speccy.piriform.com/results/chcHYviZc3GSIwWhf1x2qbM

All help is appreciated
 

Attachments

This may be a little tricky. With this sort of crashes we typically need a kernel dump located at C:\Windows\MEMORY.dmp, but from the logs I see there is no such kernel dump.

Could you double check the system recovery configuration is set for kernel dump
  1. Open Settings app
  2. Go to System and scroll down to About, click on it
  3. Go to Advanced system settings
  4. Under the section Startup and Recovery click Settings
  5. At the dropdown in System Failure, select Kernel memory dump!d
  6. Click OK, you can close the prompts now

Based on the stack in both minidumps, there's one driver waiting on multiple objects, which makes sense with this crash that's simply put about multiple processes taking longer than expected to complete. To find the causes (there are most likely multiple) and to give proper advice/suggestions, we'll need a kernel dump.
Code: 
Bugcheck code 00000133
Arguments 00000000`00000001 00000000`00001e00 fffff803`c11c33a0 00000000`00000000
Debug session time: Sun Jan 26 08:43:01.648 2025 (UTC + 1:00)
System Uptime: 0 days 4:39:18.454
7: kd> knL
 # Child-SP          RetAddr           Call Site
00 ffff8080`9d587cd8 fffff803`c0575129 nt!KeBugCheckEx
01 ffff8080`9d587ce0 fffff803`c0567b61 nt!KeAccumulateTicks+0x589
02 ffff8080`9d587d50 fffff803`c046ebfb nt!KiUpdateRunTime+0xc9
03 ffff8080`9d587dd0 fffff803`c04702ad nt!KeClockInterruptNotify+0x96b
04 ffff8080`9d587f50 fffff803`c087be9e nt!KiCallInterruptServiceRoutine+0x2ed
05 ffff8080`9d587fb0 fffff803`c087c6ac nt!KiInterruptSubDispatchNoLockNoEtw+0x4e
06 fffffc0f`fa7b6db0 fffff803`c04619a0 nt!KiInterruptDispatchNoLockNoEtw+0x3c
07 fffffc0f`fa7b6f40 fffff803`c046f117 nt!KeSetEvent+0x540
08 fffffc0f`fa7b6fd0 fffff803`c046e13f nt!IopCompleteRequest+0x117
09 fffffc0f`fa7b70a0 fffff803`c0543835 nt!KiDeliverApc+0x5af
0a fffffc0f`fa7b7140 fffff803`c0472d83 nt!KiSwapThread+0x9d5
0b fffffc0f`fa7b71d0 fffff803`c041b6ae nt!KiCommitThreadWait+0x483
0c fffffc0f`fa7b7260 fffff803`a2133aa6 nt!KeWaitForMultipleObjects+0x56e
0d fffffc0f`fa7b7360 ffffd581`9f7641b0 ftser2k+0x3aa6
0e fffffc0f`fa7b7368 00000000`00000000 0xffffd581`9f7641b0
 
It'll be too big to upload here probably. If another crash occurs with code 0x133, you can upload it to onedrive, google drive, dropbox or any other similar service you prefer, and post a share link. Please do check that we can download the file without needing to request permissions.
 
You are running 24H2 and you have a WD Black SN850X as your system drive. There is a known issue with some WD NVMe SSDs and 24H2 that can only be fixed by updating the firmware for the SSD. Download WD Dashboard and use that to update the SN850X firmware, see whether that solves the problem. It might.
 
The WD Black SN850X is not my system drive, it is drive D and was not installed in this computer when the operating system was installed. It does have the current firmware. The operating system was installed on a new Samsung 990 Pro 4TB drive. Once I thought my new computer was running properly I transferred the storage drives from my old computer to the new one about 2 weeks ago.

No crashes last night. Backup programs did run to completion. Chrome and WhatsApp were running, Outlook was not although it was during previous crashes (trying to keep things simple). Will keep Outlook running.
 
No crashes in a week so I thought I would update.

Apparently ASUS driverhub installed updates to the AMD Graphics Driver and to the MediTek Wi-Fi driver the day after the crashes. I do not use the onboard graphics and do use wired internet.

A few days ago I discovered a loose USB cable to a hub for my Keyboard and backup power supply which explained why I kept getting message from the backup power that it was connected to the computer. What makes this interesting is that the minidump reported "FAILURE_BUCKET_ID: 0x133_ISR_ftser2k!unknown_function" If I understand correctly, ftser2k is involved in USB, so could the flakey connection have caused this to puke?

If everything stays good for another 24 hours I will mark this solved (since there is not a "It went away" option)
 
Crashed and rebooted last night while idle except for maybe backup running. Link to kernal dump attached.

Clue? My keyboard (daskeyboard mechanical) did not work this morning until I unplugged it from the computer and plugged it into another port. Moved back to original port and still worked. It has been occasionally flakey for a few weeks, thought it was the hub it was plugged into, bought a new hub and still issues so plugged straight to the computer. UPS has been a lot happier without keyboard plugged into same hub.

Dropbox
 
Could you update or reinstall the software related to the hub, or plug the essentials directly into the computer instead. The ftser2k driver seems to be playing a role here.
Code: 
6: kd> lmvm ftser2k
Browse full module list
start             end                 module name
fffff802`c53f0000 fffff802`c540b000   ftser2k    (no symbols)           
    Loaded symbol image file: ftser2k.sys
    Image path: \SystemRoot\system32\drivers\ftser2k.sys
    Image name: ftser2k.sys
    Browse all global symbols  functions  data
    Timestamp:        Mon Jul  5 14:37:48 2021 (60E2FD1C)
    CheckSum:         00020184
    ImageSize:        0001B000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
 
The hub had no software or drivers. I have updated/reinstalled the AMD chipset drivers from ASUS that maybe includes ftser2k.sys I also installed ftser2k.sys using the link at ftser2k.sys

I have disconnected the hub and plugged the UPS communication USB directly into the computer's back panel, along with the keyboard. Next step might be to try a different keyboard (I don't like changing too many things at one time when trouble shooting).

I will watch my UPS logs to see if the communication issues go away.

Thanks
 
No crash last night but message this morning that last USB device plugged in was not recognized. Lights on the keyboard but unresponsive. Without unplugging keyboard, plugged another into a front port - works fine. I have unplugged the previous keyboard. Occasional disconnects still appearing in the UPS log.

Scrolled through the System event log, did not see anything obvious. Lot of messages about network link lost on the 10G port (not used), disconnected on 2.5G port (in use).

Hope this is not a motherboard problem, will see how it goes with a different keyboard.
 
Unless I'm misunderstanding, to me it sounds more like the keyboard itself is potentially causing problems there.
 
Crashed last night with different keyboard in different port. From the minidump:

DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000001, The system cumulatively spent an extended period of time at
DISPATCH_LEVEL or above.
Arg2: 0000000000001e00, The watchdog period (in ticks).
Arg3: fffff807cedc33a0, cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, which contains
additional information regarding the cumulative timeout
Arg4: 0000000000000000


near the bottom:

SYMBOL_NAME: ftser2k+3aa6

MODULE_NAME: ftser2k

IMAGE_NAME: ftser2k.sys

STACK_COMMAND: .process /r /p 0xffffe38f6a559040; .thread 0xffffe38f8358e040 ; kb

BUCKET_ID_FUNC_OFFSET: 3aa6

FAILURE_BUCKET_ID: 0x133_ISR_ftser2k!unknown_function


These crashes appear to happen when I have not interacted with the computer for a few hours, but can go for a week without crashing just to make things difficult.

Researching ftser2k.sys it appears to be the driver for the chip to run a COM port from USB. I found it in Device Manager under Ports - USB Serial Port (COM3). Since I don't use the serial port, thinking of Disabling it to see if that solves the problem. If so, then this is maybe a motherboard hardware issue?

Thoughts?
 
Instead of making system changes, I would recommend to RMA the motherboard instead. If it is already causing problems, there's a chance it could get worse soon, or you'll have a partially working motherboard.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top