Delphi 10 Seattle调试运行时包时调试器跳转到CPU视图问题求助
Hey there, let’s tackle that frustrating debugging issue you’re facing with Delphi 10 Seattle and your runtime BPL setup—where the debugger jumps to the CPU view instead of hitting your breakpoints and letting you inspect variables. I’ve dealt with this exact scenario (host apps/services + runtime BPLs) plenty of times, so here are the most reliable fixes to get your debugging back on track:
1. Double-Check Debug Information & Symbol Files
The #1 cause of this issue is missing or mismatched debug symbols. Make sure every project (host + all BPLs) is configured to generate proper debug data:
- For each project, open Project Options > Delphi Compiler > Linking:
- Set
Debug informationtoDetailed - Check
Local symbols - Set
Symbol reference infotoReference info
- Set
- Confirm you’re using the Debug build configuration for all projects—release builds strip out debug symbols entirely, forcing the debugger to fall back to CPU view.
- Clean all project outputs (
Project > Clean) and rebuild everything from scratch to ensure no stale, mismatched.dcuor.bplfiles linger.
2. Tell the Debugger Where to Find Your BPL Symbols
Delphi needs explicit paths to locate your BPL’s symbol files:
- Go to Tools > Options > Debugger > Symbol Path and add the output directories of all your BPL projects.
- After launching the host app, check View > Debug Windows > Modules to verify your BPLs are listed with "Symbols Loaded" status. If they aren’t, right-click the module and select "Load Symbols" to point the debugger to the correct
.bpl/.dcufiles.
3. Tweak Debugger & Compiler Options
A few misconfigured settings often trigger the CPU view fallback:
- For all projects, disable code optimization: Go to Project Options > Delphi Compiler > Optimization and uncheck
Optimize code. Optimizations rearrange code flow, making breakpoints unreliable. - Enable debug DCUs: In the host app’s Project Options > Debugger > Debugger Options, check
Enable debug DCUs. This lets the debugger step directly into your package code without relying solely on external symbols. - In Tools > Options > Debugger > General, ensure
Load all symbolsis enabled (avoid skipping symbols for custom modules—only skip system modules if you’re sure).
4. Handle Windows Service Debugging Quirks
Since your host is ultimately a Windows service, debugging it directly via the Service Control Manager can cause limitations. Instead, run it as a console app during debugging:
Modify your service’s .dpr file with this snippet to toggle debug mode:
program MyServiceHost; uses Vcl.SvcMgr, MyServiceUnit in 'MyServiceUnit.pas'; {$R *.res} begin // Run as console app for debugging if ParamStr(1) = '/debug' then begin with TMyService.Create(nil) do try Start; WriteLn('Service running in debug mode. Press Enter to stop...'); ReadLn; Stop; finally Free; end; end else begin if not Application.DelayInitialize or Application.Installing then Application.Initialize; Application.CreateForm(TMyService, MyService); Application.Run; end; end.
Launch the host with the /debug parameter, then attach the debugger directly to the console process—this avoids service-specific debugging restrictions that often lead to CPU view.
5. Validate BPL Dependencies & Architecture
- Ensure your BPLs are compiled in dependency order (infrastructure/model BPLs first, then the main BPL, then the host). Out-of-order builds can create symbol mismatches.
- Never mix 32-bit and 64-bit builds. If your host is 32-bit, all BPLs must also be 32-bit, and vice versa. Mismatched architectures will break symbol resolution entirely.
6. Reset Debugger Settings (Last Resort)
If all else fails, corrupted debugger config files might be the culprit:
- Close Delphi, then delete the
bds.inifile (typically located atC:\Users\<YourUser>\AppData\Roaming\Embarcadero\BDS\17.0for Delphi 10 Seattle). - Restart Delphi and reconfigure your debug settings from scratch.
内容的提问来源于stack exchange,提问作者Jan Drozen

