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?
Run the tool
Download
QuantVPS-Diagnostic.zipon your VPS.Double-click the zip → And then Double-click the
QuantVPS-Diagnostic.batThe scan runs (1–3 minutes), then opens an HTML report in your browser.
The tool scans the last 60 days 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.
Reading the report
There are 5 tiles at the top, color-matched to the severity badges in the table below:
Tile | What it counts |
HIGH (red) | High-severity events — system crashes, NIC drops, IP conflicts, RDP listener down, BugCheck stop codes, WHEA hardware errors, server-side RDP errors |
MEDIUM (amber) | Medium-severity events — app/service crashes, failed RDP logins, IPsec drops, abnormal RDP disconnects, Group Policy failures |
INFO (gray) | Informational events — boot, successful logins, planned reboots, RDP blips, demoted context |
PLANNED REBOOT (indigo) | User-initiated reboots (Event 1074) and Windows Update restarts (Event 22). Not crashes. |
TOTAL | Every row in the table |
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:
Time — when it happened, in the VPS's local time
Event ID — for cross-referencing
Category — a colored chip plus a short description. The chip tells you the type at a glance.
Severity — pill-shaped badge: HIGH / MEDIUM / INFO
Message — Windows' original event text, truncated to ~360 chars
Rows tagged BOOT get a subtle gray background to visually group them as boot side-effects.
The category chips
Chip | Meaning |
NET | Core network plumbing — NIC, IP, NetworkProfile |
DNS | DNS resolution events |
RDP-VPS | Server-side RDP problem (listener died, connection-stack error) |
RDP-NET | Network-side RDP disconnect mid-session |
RDP-AUTH | Failed RDP login attempt |
RDP-OK | Successful RDP connection / reconnect |
RDP-BLIP | Transient disconnect+reconnect pair that auto-recovered |
BOOT | Boot or boot side-effect (NIC cycle, planned shutdown, etc.) |
CRASH | Unexpected reboot / BSOD / hardware error |
HW | WHEA hardware events (CPU, RAM, PCIe) |
SERVICE | A Windows service crashed |
APP | A user-mode application crashed or hung (TWS, NinjaTrader, Python, etc.) |
UPDATE | Windows Update install or restart |
USER-REBOOT | Manual reboot initiated from within Windows |
SECURITY / IPSEC / FIREWALL / NPS / GP | Security-related failures |
What the tool is smart about
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.
Match RDP/network issues against your broker
For network-side problems, line up timestamps from three sources:
The exact time you saw the drop — screenshot it or note it.
Your broker's disconnect log — NinjaTrader, Tradovate, Rithmic, IBKR, TradingView all timestamp session drops.
The Event Viewer report from the tool.
Then:
Broker drop + report shows a HIGH event at the same time → VPS-side. We can fix it.
Broker drop + report empty at that time → the VPS held; the issue was your local internet, ISP, or broker.
No broker drop + report shows blips → brief network hiccup the broker session survived.
Application crashes (TWS, NinjaTrader, Python, etc.)
Trading-app crashes show up under the APP chip via three events:
Event | What it catches |
1000 | Native app crash — faulting application + faulting module name + exception code |
1002 | Application hung — the "Not Responding" state |
1026 | .NET unhandled exception — common for NinjaTrader |
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.
Contact support
Open a ticket and attach:
The HTML report (
QuantVPS-Diagnostic-YYYY-MM-DD_HHMM.htmlfrom your Desktop)The exact time(s) you saw the problem, in the same time zone as the report (e.g. "1:42 PM ET on May 3")
A description of what you saw — did the whole VPS reboot? Did the trading app close? Did RDP drop? Did anything appear on screen?
For RDP/network issues: a screenshot of your broker's disconnect log if available
For BSODs: if there's a recent dump at
C:\Windows\Minidump\*.dmp, attach the most recent one — support can run it through WinDbg's!analyze -vfor the full call stack
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.
Scanning a different time window
The tool defaults to the last 60 days (-HoursBack 1440). To use a different window, open Command Prompt as administrator in the folder where you saved the file and run, for example:
QuantVPS-Diagnostic.bat -HoursBack 720
That example scans the last 30 days. Other common values: 24 = last day, 168 = last week, 720 = last 30 days, 1440 = last 60 days (default).
Event ID reference
Network / RDP
Event ID | Source | Default severity | What it tells you |
27 | NIC driver / NDIS | HIGH | NIC link disconnected |
10000 / 10001 | NetworkProfile/Operational | info / HIGH | Network connected / disconnected |
4199 | Tcpip | HIGH | IP address conflict |
1014 | DNS Client | low | DNS resolution timeout |
55 | UniversalTelemetryClient/Operational | info | Internet availability check |
5827 / 5828 | Netlogon | MEDIUM | Vulnerable secure-channel denied (CVE-2020-1472) |
2021 / 2022 | Srv | HIGH | Server connection / work-item exhaustion |
4960–4965 / 5453 | Security | MEDIUM | IPsec |
5027–5037 (failures only) | Security | MEDIUM | Windows Firewall |
6273 / 6274 | Security | MEDIUM | NPS denied access |
6145 | Security | MEDIUM | Group Policy security |
1030 / 1053 / 1054 / 1058 | Application | MEDIUM | Group Policy processing |
1158 | RemoteConnectionManager/Operational | HIGH | RDP listener stopped — VPS reachable but RDP broken |
40 | LocalSessionManager/Operational | MEDIUM | RDP session disconnected (clean disconnects filtered out, reason code decoded) |
24 | LocalSessionManager/Operational | MEDIUM | RDP session disconnected (general signal) |
39 | LocalSessionManager/Operational | info | RDP session takeover (another user bumped this one) |
25 | LocalSessionManager/Operational | info | RDP session reconnected (orphan only — paired-with-1149 ones are filtered) |
1149 | RemoteConnectionManager/Operational | info | Successful RDP login (source IP + username) |
227 | RdpCoreTS/Operational | HIGH | Server-side RDP connection-stack error |
4625 (LogonType 10) | Security | MEDIUM | Failed RDP login |
Crashes / Stability
Event ID | Source | Default severity | What it tells you |
41 (Kernel-Power) | System | HIGH | Unexpected reboot / BSOD |
1001 | WER-SystemErrorReporting | HIGH | Bugcheck (BSOD stop code) — stop code decoded inline |
6008 | EventLog | HIGH | Previous shutdown was unexpected (paired with 41 = same incident) |
17–20, 46, 47 | WHEA-Logger | HIGH | Hardware error |
1003 | System | HIGH | Legacy bugcheck format |
7031 / 7034 | Service Control Manager | MEDIUM | Service crashed unexpectedly (cloud-VPS noise auto-demoted) |
7026 | Service Control Manager | MEDIUM | Boot driver failed to load |
1000 / 1002 / 1026 | Application | MEDIUM | App crashed / hung / .NET runtime crash |
Context (used for reclassification)
Event ID | Source | Severity | What it's for |
12 | Kernel-General | info | OS started — anchors reboot-cluster detection |
19 / 20 / 22 | WindowsUpdateClient | info / MEDIUM / info | Windows Update install / failure / restart |
109 | Kernel-General | info | Planned shutdown |
1074 | User32 | info | User-initiated shutdown/reboot |
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.
Need Assistance?
Our support team is available 24/7. If you have any questions or run into issues, open a support ticket from your QuantVPS dashboard and we'll get back to you as quickly as possible.
