Jump to content

MusicProg1

Members
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
×