Delphi XE7 sometimes only will show CPU view when debugging my 64-bit app, and module entry points not showing in Modules view for main exe.

[MusicProg1 0]

I'm running Delphi XE7, and mysteriously/randomly Delphi XE7 will sometimes ONLY show the CPU view when debugging my 64-bit Windows app, and not let me step through any Pascal source.  It will stop on a breakpoint but only show CPU view when the breakpoint is hit, and right click - View Source does nothing.   When this occurs,  if I go to the Modules view, none of the entry points and addresses are showing up for the program's  .EXE itself.   I can debug a .DLL module used by my project, that was compiled in Delphi, because the module entry points and addresses do show up when I click on that .DLL in the modules window, unlike when I click on the main .EXE in that same Modules window.

 

When this issue occurs, quitting Delphi and restarting it does not resolve it.   

 

If I reboot the entire computer,  this issue can resolve itself but may start happening again the same day.  Today it occurred, and I rebooted, and it resolved it, but then it happened the 2nd time I ran the program in the IDE, which is very frustrating.    I have yet to find a way to get the issue to resolve without rebooting.     

 

When this issue occurs with my project, I'm able to load a different 64-bit Delphi project and debug it, so it is not a matter of the XE7 debugger itself failing to load module entry points for the main .exe of all 64-bit apps, just the project I want to work on, and it's very mysterious, because I've gone a week or two at a time without the issue occurring with my project and then it happens and rebooting the machine is the only thing that may resolve it, at least temporarily.    

 

By the way, the Modules view does show the Base Address, Module Name and .rsm file for the program's .EXE but, again, when you click on the main exe then none of the entry points and addresses are showing up. 

 

I'll also mention that I can debug other projects with the same settings as my project when this issue occurs.      When this issue occurs, and the main .EXE module is loaded for my project the Event Log does still indicate that the main .EXE has debug info.     

 

Any idea why this is occurring, and will it still occur after  upgrading to the latest version of Delphi?   I keep getting sales calls about upgrading.   This was never an issue when I debugged 32-bit apps. 

 

Thanks,

 

J.   

Edited May 28, 2020 by MusicProg1
added more detail

[MusicProg1 0]

For many months simply setting the target folder to a DIFFERENT folder than the project folder resolved the issue, but today this issue is now back and can't figure out any solution.   Again, I'm running XE7 and upgrading is not an option right now.  Would be nice to know what is causing the entry points for main module to not show up in the Modules window, and why Mixed Source will not show any pascal in the CPU window, and View Source fails to switch to the pascal source, and when a debugger breakpoint is reached it immediately goes just to the CPU window.     Thanks.  J. 

Edited December 2, 2020 by MusicProg1

[MusicProg1 0]

Discovered that I can run the program without debugging and then Attach to Process and that lets me debug and be able to step through the source code and not just the cpu view.   

 

I also tried LoadProcess , but that doesn't let me debug with the source code.   If I select the option to have it not run upon loading, and then visit the modules window after loading, and click on the main module, then it does show all the entry points, but if I proceed and run the process with, say, the F8 key, then it still can't debug.  I would have to detach and re-attach to get it to be able to debug with the source code. 

Edited December 3, 2020 by MusicProg1

[Guest]

all setup from user (files) stay on "c:\users\<user-win>\AppData\Roaming\Embarcadero\BDS\<IDE_number>

• just delete "DEBUG.dst" or all *.dst files!
• this files will be recreated by IDE or when you save a new "desktop" view!
• you can, include, edit it with any text-editor!

 

if you can try my file - never changes since installation!

 

Debug Layout.dst

Default Layout.dst

Startup Layout.dst

[MusicProg1 0]

Thanks for the reply.  I tried your dst files, but didn't seem to resolve the issue where you can only see the cpu view and not the source when debugging. 

Edited December 3, 2020 by MusicProg1

[Guest]

• VERIFY YOU .DCU -- IF THE ACCESS IS POSSIBLE WHERE IT WAS GENERATED!

Opening the Entire CPU View

To open the Entire CPU view during a debugging session, do any of the following:

• Choose View > Debug Windows > CPU Windows > Entire CPU.
• Press Ctrl+Alt+c while any IDE window has focus.
• Right-click the Code Editor and choose Debug | View CPU from the context menu.

The CPU window also opens automatically whenever program execution stops at a location for which source code is unavailable. For example, the debugger cannot open the source file if you link a DLL (Windows) built with debug information but do not include its source file in your project, or if you place the source file in a directory not specified in your project.

Edited December 3, 2020 by Guest

[MusicProg1 0]

Thanks for the reply.  The source, most definitely, is still there, just like it was for the past couple months when the issue wasn't happening.   Even if I set breakpoints in the program's main .DPR it just goes to the CPU window and only shows assembly code, and mixed source doesn't show any source code.   The message window does indicate that the breakpoint occurred in the .DPR and even indicates the line number of the breakpoint, but yet I only get the CPU window without mixed source showing (even when checked) and view source doesn't do anything.  This is true whether I set a breakpoint in the .DPR or any of the .PAS files of my project.  Right now, only if I run the program without the debugger, and use Attach to Process, am I able to debug my program in the IDE with the debugger showing source code the way it normally should.  I just would like it to go back to working when I run the program in the IDE normally and not having to attach to process after running it.   Thanks.   

Edited December 3, 2020 by MusicProg1

[Guest]

For sure, that will be the solution:

• if you license allow new installation in the same MSWindows (or in a new clean O.S. install)
• uninstall the RAD and restart OS
• on Registry, delete all to: Embarcadero keys
• on disk, delete all residual files (dcu, bpl, etc...) in special in hide folders (C:\ProgramData  and C:\Users\<<your-user>>\...AppData\Roaming\Embarcadero
• restart OS and reinstall your RAD!
• ... and goobye yellow brick road...

[MusicProg1 0]

After re-booting up a 4th time it's now debugging normally again.  I did also run one of Windows' routines that deletes unused temp files although I don't know if that helped or not.  So far, the problem seems random.  It could go months between the next time it happens again or go 5 minutes.   At least I have the method of attaching to process to still be able to to debug without rebooting if it occurs again.  This never occurred with a 32-bit target, only 64-bit. 

[MusicProg1 0]

Oh, and when this occurs, it doesn't happen with all programs at a time.  Just the one I mainly work on, and even restoring backups of the project doesn't resolve it.

[Guest]

2 hours ago, MusicProg1 said:

Oh, and when this occurs, it doesn't happen with all programs at a time.  Just the one I mainly work on, and even restoring backups of the project doesn't resolve it.

my tip:

• IF exist some problem with your "Project - Options" this project, then, just create a new project and add your units/forms into it!
• later, if necessay just adjust the options used in old project!

[MusicProg1 0]

Actually I tried that and expected it to work, but it didn't.  I created new project and copied settings using cut/paste from old to new and it still wasn't debugging which was weird.

[Guest]

13 hours ago, MusicProg1 said:

Actually I tried that and expected it to work, but it didn't.  I created new project and copied settings using cut/paste from old to new and it still wasn't debugging which was weird.

look, never is good idea "copy/paste" in many situation, mainly when "ghost"-chars appears on files! ok - I think that is not your case!

my last tip:

• when all try dont works, I begin from the start!
• format c; 😄 and all solve! FOR ME!

good luck

hug

[MusicProg1 0]

It turned out that, even though I feel this issue shouldn't have occurred and was due to a bug in XE7,  it was happening to my program because it was using a .DLL that was compiled in XE7, and had debugging info in it.   If I rename the .RSM file for the .DLL so that XE7 doesn't find it, then it successfully loads the RSM file for the main program and I'm able to debug the main program without having to attach the debugger to an already running process of my app.