Diagnosing VPS Issues — Network, Crashes, and Stability

When something goes wrong on your QuantVPS — a disconnect mid-trade, the trading platform crashed, the VPS rebooted on its own, RDP wouldn't connect — you want one answer: what actually happened?

#1 Download QuantVPS-Diagnostic.zip on your VPS.

#2. Double-click the zip → And then Double-click the QuantVPS-Diagnostic.bat

#3 The scan runs (1–3 minutes), then opens an HTML report in your browser.

The tool scans the last 2 weeks of Windows event logs and writes the report to your Desktop. It also installs a permanent custom view in Event Viewer named QuantVPS Diagnostic — open Event Viewer any time (Start → type eventvwr) and navigate to Custom Views → QuantVPS Diagnostic to browse events live. No internet access required, nothing uploaded.

There are 5 tiles at the top, color-matched to the severity badges in the table below:

The card's left border color mirrors the worst severity present — red, amber, or green — so you can tell the overall state at a glance.

Below the tiles, each event row has:

Rows tagged BOOT get a subtle gray background to visually group them as boot side-effects.

This is what differentiates the report from raw Event Viewer:

Reboot clusters. When the VPS reboots, the network stack cycles. Events like NIC disconnect (27), DNS timeout (1014), NetworkProfile (10000/10001), and RDP session terminated (40) within 5 minutes of an OS boot (Event 12) get demoted to info with the BOOT chip and category "Reboot side-effect…". They're routine, not problems.

User-initiated reboots. If you (or shutdown.exe, or an app) initiated a restart, Event 1074 is logged. Any Kernel-Power Event 41 within 5 minutes after a 1074 gets reclassified from "Unexpected reboot" to "Planned reboot (user-initiated)" and tagged USER-REBOOT. Manual reboots no longer inflate the HIGH tile.

Windows Update reboots. Event 22 (Windows Update restart) within 10 minutes of a Kernel-Power 41 demotes the 41 to "Reboot for Windows Update (reclassified)" with the UPDATE chip. Patch Tuesday isn't a crash.

RDP blips. Event 40 (RDP disconnect) paired with a subsequent Event 25 (reconnect) within 2 minutes is a transient network hiccup that self-recovered. Both events get tagged RDP-BLIP and demoted to info. The Event 40 reason code is decoded too — 2147942521 becomes "Network timeout (Win32 0x79 ERROR_SEM_TIMEOUT) — TCP connection timed out" in the Note.

Crash incident pairing. A forced power-off normally logs both Event 41 (Kernel-Power) and Event 6008 (previous shutdown was unexpected). The tool pairs them as one crash incident so the HIGH count reflects the actual number of crashes, not 2× per incident.

BugCheck stop-code decoding. When Event 1001 (BugCheck) fires, the tool extracts the 0xXXXXXXXX stop code and decodes it inline. Instead of just "Bugcheck (BSOD stop code)", you'll see:

Stop 0x0000003B SYSTEM_SERVICE_EXCEPTION — exception in a system service, usually a driver (mentions nvlddmkm.sys)

The faulting module hint comes from a regex looking for any .sys/.dll/.exe filename in the message text.

Known cloud-VPS noise. Services like cloudbase-init, ec2config, AmazonSSMAgent, WindowsAzureGuestAgent, and drivers like dam, igdkmd64 get auto-demoted with the explanation "Safe to ignore." They fail on every reboot of cloud Windows images — not real crashes.

Duplicate login rows filtered. Every fresh RDP login logs both Event 1149 (auth succeeded) and Event 25 (session attached). The 25 within ±5 seconds of a 1149 gets dropped from the table. Only orphan 25s remain — those are transparent reconnects after a blip, which is the useful signal.

For network-side problems, line up timestamps from three sources:

Then:

Trading-app crashes show up under the APP chip via three events:

App crashes don't crash the whole VPS. They land in MEDIUM, not HIGH. If TWS dies and you see Event 1000 with TWS.exe / jvm.dll / 0xc0000005, that's TWS hitting a JVM access violation — not a system crash.

Most trading apps don't log network events to Windows event log (they log to their own files), so a "broker disconnect" inside the app won't appear in this report unless the app actually crashed or hung as a result.

Open a ticket and attach:

The report tells us what the VPS logged; your context tells us what you experienced. Together they let us pinpoint whether the problem was VPS-side, network-side, broker-side, or local.

The tool defaults to the last 2 weeks. To use a different window, open Command Prompt as administrator in the folder where you saved the file and run:

Common values: 24 = last day, 168 = last week, 336 = last 2 weeks (default), 720 = last 30 days.

Most events get reclassified by the post-processing — for example, a 7034 firing within 5 minutes of a 1074 becomes "Service stopped during reboot" with info severity, not "Service crashed unexpectedly" with MEDIUM.