You’re right — this is one of those intermittent, low‑level “gremlin” hangs that’s annoying to track down. The symptom you described (full system unresponsive, keyboard lock‑LEDs not toggling) most often points to a kernel/firmware/IO hub or power delivery hang rather than a normal app crash, so we need to triage methodically rather than guessing. That’s the approach I recommended earlier.
Quick summary of what’s been tried (so we don’t repeat work)
- You checked Event Viewer and ran memtest already.
- You’re using a PS/2 mouse through an 8‑port KVM and the freezes are unpredictable (a few in a short span, then nothing).
Recommended prioritized checklist (do these in order — short steps first)
1) Kill the KVM / isolate input
- Temporarily take the T3500 off the KVM and plug a mouse/keyboard directly into the PC (use the back‑panel ports). If that’s inconvenient, try a PS/2→USB adapter or a different PS/2 mouse/port. Many silent hangs on old Dells show up when legacy input is routed through a KVM.
- Expected outcome: if hangs stop, the KVM or how it negotiates PS/2 signals is likely the trigger.
2) Simple software checks (low risk, quick)
- Boot to Safe Mode or do a Clean Boot (msconfig → selective startup). Leave it running for the period you usually see freezes. If it never freezes in Safe Mode/clean boot, suspect a driver/service.
- Disable “USB selective suspend” and set Power Plan to High Performance while testing (in Control Panel → Power Options).
3) Make Windows create usable dumps (if possible)
- Set Windows to write a Kernel memory dump (Start → System → Advanced system settings → Startup and Recovery) and ensure the pagefile is >= RAM size so dumps can be written if Windows can. I can paste the exact registry keys to enable the “Crash on Ctrl+Scroll” hotkey if you want to force a dump when observed.
4) Log sensors while idle and under stress
- Install HWiNFO64 and enable sensor logging to CSV (voltages, temperatures, clocks). On older Dells the board may not expose many sensors, but HWiNFO will capture what’s available. Run a stress test (Prime95 small‑fft for CPU, and optionally a GPU loop) while logging. Look for sudden voltage drops or temperature excursions just before a freeze.
- If the motherboard exposes little, consider the simplest external checks first (see PSU checks).
5) Minimal hardware isolation
- Remove all non‑essential devices: extra PCIe cards, USB dongles, extra HDDs, etc. Boot with one RAM stick (rotate sticks and slots), onboard video (or swap GPU), and no extra controllers. Run until the freeze either recurs or is gone. If it stops, add parts back one at a time until it returns. This often identifies the flaky component.
6) BIOS / onboard controller isolation (very useful on old Dell boards)
- Temporarily disable non‑essential onboard controllers in BIOS one at a time (audio, FireWire, extra SATA controllers, extra NICs). Run a day after each change. On T3500 boards a southbridge/chipset controller can lock and cause exactly the behaviour you see; disabling controllers is a cheap way to catch it.
7) PSU / power delivery checks
- Inspect PSU and motherboard caps for bulging or leakage. If you can, test with a known‑good PSU or at least try powering the system from a different wall outlet (bypass UPS) to rule out an external power issue. Intermittent rail dips produce the type of full hang you describe.
8) Advanced (if logs point to drivers)
- Run Driver Verifier for suspect drivers (only if you can analyze BSOD dumps or recover from them). Driver Verifier forces faulty drivers to cause a dump so you can identify them. (It will cause crashes while active — I’ll give the exact commands if you want to try.
What to collect and post here (so I can analyze)
- Last ~20 lines from Reliability Monitor after a freeze and the System log entries around the time (filter WHEA‑Logger, LiveKernelEvent, Kernel‑Power).
- HWiNFO CSV sensor log (if available) leading up to a freeze.
- MemTest86 (bootable) result if you re-run it for multiple overnight passes.
- Full system spec: exact CPU model, GPU model, motherboard model and BIOS version, PSU make/model, RAM part numbers, list of PCIe cards and external devices.
Quick suggestions based on your notes
- Since you already replaced the PSU once and the machine is old, start with BIOS controller disabling and KVM isolation — both are cheap, non‑destructive tests that have caught this exact symptom in T3500 systems.
- If you don’t want to swap PSUs, forcing better diagnostics (kernel dumps + sensor logs) is the next best step so you don’t replace parts blind.
If you want, I can:
- Paste the exact registry entries and commands to enable Crash-on-Ctrl+Scroll and to configure kernel dumps.
- Walk you through HWiNFO64 sensor logging setup and what columns to watch.
- Help parse the Reliability Monitor / Event Viewer output if you paste the last lines here.
Which of the above do you want to try first? If you prefer, start with “disconnect from the KVM and plug directly” and report back whether the freeze recurs — that’s the quickest high‑value test.