I am writing a plugin for the AIMP music player, which is itself closed source but has documentation for adding plugins. The interface is available in Delphi, hence I am figuring out how to use RAD Studio Delphi 10.3 Community Edition.
I have stumbled upon a situation that is either of these:
Something is wrong with how I call the AIMP Methods or how I set up the parameters
Something is wrong with the Method I am calling
I have set up the Run Parameters so that the AIMP Program is actually launched when I press "Run". I have also enabled Tools > Options > Debugger > Embarcadero Debuggers > Debug spawned processes. However, the program did not stop at my breakpoint and there was a grey X icon displayed in front of the breakpoint.
Turns out this was because I also had a version of the compiled dll in the AIMP Plugin directory so it was loading that old version and not my newly compiled one. But even when I remove the old version... how can I get it to actually call the new version?
When I build my dll and paste it into AIMP's Plugin directory, it will be loaded and the settings screen reflects that. I can even show a Message Box when the settings are being modified by the user. But copying the dll over means I can't stop at breakpoints.
How can I make the debugger stop at my breakpoint so that I can step through the program, ideally being able to see the values of local variables?
Under Project > Options > Building > Delphi Compiler there is the option Output directory. Setting this path for the relevant Build Configurations to the AIMP Plugin directory did the trick, as suggested by #Brian in this comment.
Related
I'm trying to debug as always in VS 2019. Recently, for some reason, when I hit a breakpoint in specific .cs files the Locals window is empty. However, in other files locals are available! When I use Immediate Window in the files where locals are empty, I get "Unable to evaluate expression". But same command in other parts of the code is working.
Context:
Project is a C# library (dll) which loads as a plug-in in another application (Revit)
The pdb file is located in the same directory as the dll
Project is using Fody Weaver. However I've been using it before and I weren't having debugging issues with it.
Advanced build settings are as follows:
I attach to the process using Debug > Attach to Process and the Automatic option:
I am attaching in the Debug mode and the dll is built using Debug mode as well.
The "Optimize Code" option is unchecked.
Things I have tried:
Enabled "Use Managed Compatibility" mode
Enabled "Suppress JIT optimization on module load"
Enabled "Just My Code"
Deleting breakpoints and creating the again
Cleaning solution and rebuilding
Restarting Visual Studio
Starting Visual Studio as an administrator
Updating Visual Studio to latest
Restarting my computer
Update:
I tried refactoring and splitting the file where locals aren't showing, into two files. To my surprise now the locals are showing both in the file where they weren't showing before and in the new file. However, the values shown are still weird. The type of objects are shown as float {class} and I can't expand to see their properties. See screenshot below from locals displayed in the new file:
So in my case the issue was a virus protection software called Cylance I had installed. I changed its settings to Monitor and in the Debug settings of VS, unchecked the "Use Managed Compatibility Mode" and the locals are all showing as expected again.
Whenever a Executable is opened, the delphi IDE opens as like debug mode. what settings has changed in my IDE?
Can any one help me!
Update: 1. Build taken in other machine also causing this issue.
How come a opening an EXE, starts the IDE?
Default debugger was modified from vcjitdebugger to delphi debugger. So in case of exception delphi instance was started. It can me modified as below:
You need to delete the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
On a 64 bit system delete this key also:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
At the top of your IDE, you have a combo box with the available layouts of the IDE.
You probably have ‘Debug layout’ selected instead of ‘Default layout’ or so...
When you have opened a project, select 'Default layout' and then it will persist that choice for the next time you open a project.
I recently posted this question about my inability to get Delphi 2010 working with remote debugging. I have not had any success and decided to post up a simple step-by-step test technique that might highlight what I'm doing wrong. THIS IS REALLY IMPORTANT to me - I've used Delphi since V1.0 and earn my living from it. Being stuck like this is a pain and its keeping me on Delphi 7.
Anyway, here goes.
Ensure that Delphi 2010 has updates 4&5.
Fire up Delphi 2010, then File | New | VCL Forms App. Put a button on the form, put 'ShowMessage( 'hello' ) in the button OnClick event. Save the project and its unit in a local folder "C:\scratch". Build the project, run it, click the button, 'hello' appears, all fine.
On a networked PC (194.168.1.64), create a new folder "c:\DebugTest" and share it with R/W access.
On 194.168.1.64 install the Remote Debugger from the latest download on the Embarcadero Website (RemoteDebugger_upd2.exe). CLick rmtdbg140.exe to run. Accept the 'un-block' message from the firewall.
Edit the DEBUG build configuration compiler settings with Output directory=\192.168.1.64\DebugTest and unit output directory = c:\scratch - see
Edit the Linking settings to set Debug Information=True, Include remote debug symbols=True. See
Leave compiling settings at defaults. See
Do a full build. The relevant project exe 'project2.exe' and 'project2.rsm' appear in the remote folder \192.168.1.64\DebugTest. Blue dots are visible in Unit2 in the IDE.
Set a breakpoint on the 'ShowMessage' line (the button OnClick event).
Use 'Run' | 'Load Process' with Remote path=c:\DebugTest\Project2.exe, Remote Host=192.168.1.64 and Working directory=c:\DebugTest see
Click 'Load'. The visible breakpoint is immediately disabled, the project starts running and opens the CPU window and stops. Pressing f9 cause the exe to run fully on the remote machine, the button works, you just cannot debug it.
I've tried various 'obvious' things like firewall off but all to no avail. Could some kind person suggest further ideas?
Many thanks.
Well, for me the problem has now been solved, although as a 'work around' and after significant interaction with Embarcadero and an upgrade to XE (which also did not work).
It would appear that the remote debugger is flaky (or possibly just picky) in its ability to load rsm (remote symbols) files - they are still looking into why mine wont load. My rsm file is big at around 50Mb although this is no problem for Delphi 7's remote debugger.
The work around involved upgrading to Delphi XE and then choosing the compiler link option 'Place Debug Information in separate TDS file'. This seems to create a tds file onthe remote target instead of a rsm file and breakpoints then work fine.
I've submitted my rsm and tds files to Embarcadero for investigation as to why this happens.
What Windows OS? Maybe run rmtdbg140.exe as admin.
I run D2010 remote debugging on XP versus XP. My How-To is at http://blog.runbits.com/post/Remote-debugging-Delphi.aspx
I had this problem. Installing Update 4 for Delphi 2010 solved my problem. It is also listed in the list of fixed problems of Update 4.
It is imperative to have correct time zone and clock on remote system. In my case I set up remote debugging and when I load process the breakpoints turned green. I checked remote system timezone and clock, set it right and remote dubugger worked again.
I try to debug a COM dll (TAutoObject) in Delphi and my break point are not green.
I put my option like this :
host : c:\Program Files\Internet
Explorer\iexplore.exe
param : c:\software\test.html
My test is well lanched but no breakpoint in Delphi
what is the way to to this ?
You have to run the program which launches the COM+ object and then attach it to the process.
IE launches a sub-process which hosts non-trusted code. this is probably why your debugging settings are not working, and why attaching to the process once launched works.
Since the debugger doesn't start the file, that won't work.
IIRC you can try to "attach to process" to the process running it (iexplorer.exe), but the problem is that that doesn't allow to debug through the start of the component. (since it costs time to manually attach)
I had a different setup where I instantiated a very slightly differently compiled .ocx on a panel of a delphi app, and used that to debug. Which worked fine.d
This link Breakpoint not honored while debugging a DLL helped me debug my com dll in Delphi 5. Go to Project -> Options -> Linker -> check mark "Include remote debug symbols". I couldn't tell you why it worked. Delphi 5's help provided the following description:
Include remote debug symbols Check this if you are using remote debugging.
You also need to have integrated debugging turned on. Its on the general tab of the debugger options.
In the past what I have done is to create a separate program which invoked my COM object and used it as the target for debugging rather than the standard host. This simplifies things and also allows you to create specific repeatable tests of known issues to aid in smoke testing later.
you can also use tools like CodeSite.
I'm a .NET developer, but I have got a quest - I must find errors in a Delphi project.
After opening a project (Borland Delphi 7) and trying to debug it ('Run' menu), I've noticed all debugging options are inactive (gray).
How can I make it usable?
I'm not sure why the pause button doesn't work, but I have seen Delphi 7 get "confused" and refuse to stop on legitimate breakpoints before.
Make a backup of everything, just in case you don't have the source for all of the DCUs.
Delete the project's DCUs.
Make sure you're including debug information in the project's options.
Do a full build (not just a recompile).
I hope this helps.
The debugger is always active, unless it is explicitly deactivated. Just run the application and the inactive menu items will become active. (For some options you have to have to pause the running application)
Just try pressing F8. This will run the application and pause at the first line of executable code and most of the debugging items will become active.
Hard to tell just from that description, but here are a few pointers.
Make sure you've got a project (.dpr) loaded, and not just a source (.pas) file.
Try to build the project with SHIFT-F9. When it's done, if everything compiles successfully, you'll see blue dots in the "gutter" at the left side of the text editor, showing which lines actually contain debuggable code. If you don't get any of those, go into Project Options and turn on the Debug option, then rebuild.
Once you've done that you should be able to run and debug the app.
Tools-->Debugger Options
Make sure integrated debugging is checked.