使用MS Debug Diagnostic Tool分析.NET高CPU问题遇阻求助

Let's break down your problem and walk through fixes and practical approaches tailored to your production environment:

First: Are Your DebugDiag Operations Incorrect? Are Suspended Processes Normal? #

• Suspended processes are expected but excessive ones signal a problem: Those suspended processes matching your app's name are DebugDiag's standard way of capturing memory dumps without interrupting the original process—it creates a snapshot process, suspends it to write the dump, then cleans it up. However, if you're seeing lots of them lingering, this usually means dump collection is taking too long (maybe due to large process memory) or the tool is hitting a cleanup bug.
• Rule showing "Completed" prematurely: This is almost certainly a tool quirk triggered by hitting the default limit for number of dumps collected. Check your high CPU rule's "Advanced Settings"—look for "Maximum number of dumps to collect" (often set to 5 or 10). If your app spikes CPU repeatedly before the rule's duration ends, it will exhaust this limit and mark itself as completed.

Fixing the System.ArgumentException During Analysis #

That error definitely stems from duplicate process identifiers across your dump files causing a collision in DebugDiag's internal dictionary. Here's how to resolve it:

1. Rename dump files manually: Navigate to your dump directory (default path: C:\Program Files\DebugDiag\Logs\<RuleName>) and rename each .dmp file to include a unique identifier (e.g., add a timestamp or the original process ID from the filename suffix—you’ll see something like MyApp_1234_20240520.dmp if you inspect closely).
2. Prevent duplicates upfront: Edit your DebugDiag high CPU rule, go to the "Dump Location and Name" section, and enable "Append timestamp to dump file name". This ensures every dump has a unique name from the start, eliminating the duplicate key issue entirely.

Alternative: Use ProcDump (Microsoft's Free, Reliable Command-Line Tool) #

Since you’re hitting DebugDiag bugs, ProcDump is a far better fit for production—it’s lightweight, command-line only, and avoids the suspended process clutter. Here’s how to use it:

1. Grab ProcDump from the Sysinternals suite (it’s a single executable, no installation required).
2. Copy it to your production server via RDP or file share.
3. Run this elevated command to capture a full memory dump when your app’s CPU hits 90% for 10 consecutive seconds:

   procdump -ma -c 90 -s 10 MyApp.exe
   

   • -ma: Captures a full memory dump (critical for analyzing infinite loops, as it includes all thread stacks and memory)
   • -c 90: Triggers when CPU usage reaches 90%
   • -s 10: Waits 10 seconds of sustained high CPU before capturing
   • Replace MyApp.exe with your actual process name.
4. When the high CPU issue occurs, ProcDump will generate a clean .dmp file in the same directory—no suspended processes involved.

Analyzing the Dump to Find Infinite Loops #

Once you have a valid dump file, use either DebugDiag Analysis (now with unique filenames) or Windbg Preview (free, lightweight, available via Microsoft Store) to investigate:

• In DebugDiag: Select your single dump file, choose "Performance Analyzers/PerfAnalysis", and look for threads marked "Long Running". Inspect their call stacks for repetitive method calls—this is a clear sign of an infinite loop (e.g., a UDP packet processing loop where an exit condition never triggers due to malformed input or unhandled edge cases).
• In Windbg: Load the dump, run !runaway to identify threads using the most CPU time. Then run ~<ThreadID>kb to pull the full call stack for that thread. If you see the same method repeated over and over, that’s your infinite loop candidate.

Key Notes for Your Scenario #

• Since your thread count spikes to 250 but memory usage stays normal, focus on threads in active execution (not waiting on I/O or locks). High packet volume likely triggers an edge case in your processing logic—like a loop that doesn’t reset a flag, or a calculation stuck on invalid data.
• Avoid leaving DebugDiag running indefinitely in production; use ProcDump’s triggered capture to minimize overhead.

内容的提问来源于stack exchange，提问作者Marcos Arruda