What rights are needed for 64-bit debugging on Windows?
That is the short, difficult question.
An answer that makes it work using either Delphi 11.3 or Delphi 12 is what I'm looking for. (Am currently using 11.3, but could upgrade to 12 if that helps make 64-bit debugging work.)
What I know so far
I use a trivial VCL application for testing. It contains a form with a button and this event handler (that's all):
procedure TForm1.Button1Click(Sender: TObject);
var
x: Integer;
begin
x := 5;
x := x * x;
Caption := IntToStr(x);
end;
If Delphi is "Run as Administrator", then 64-bit debugging works.
When Delphi is run normally, that is, not "as Administrator" (and, interestingly, even when my current Windows user does belong to the local Administrators group), then debugging never starts visibly, except for that windows are arranged according to the Debug Layout. It never says "Running" in the Delphi IDE window's title.
Task Manager shows the participating processes running, including my program being debugged, but the program never shows up visibly, and the Delphi IDE shows no signs of having entered any debugging state.
However, if I try to close the Delphi project in this state, it seems aware that it's debugging, because it complains "This current debug session must end before the requested operation can complete." After I click Terminate, it says "Debugger fatal error during process reset: 'Debug process is already running'. Please save your work and restart Delphi 11." (In Delphi 12, it says the same but with a 12 at the end.)
Our company (IT policy) does not allow me to run as Administrator (except on specific request, but not on a daily basis). According to Embarcadero support, Admin rights are not required, but they have also not been able to provide a list of precise requirements. They have a helpful and friendly attitude, but seem to be searching for the answer themselves, is my impression.
'Debug programs' right
Giving my user the "Debug programs" right, which seems reasonable, has not made any visible difference.
Firewall
The debugger process needs to be let through the firewall (because 64-bit debugging is technically a remote debugging, also locally, because the Delphi IDE is a 32-bit application), but I think that that is in place and correct already, because if the firewall were the problem, then I presume running as administrator would not make any difference. The firewall behaves the same regardless of which user I am running as, doesn't it?
Controlled Folders
Adding $(BDS)\bin\dbkw64_28_0.exe to the "allowed apps" list for Controlled Folders in Windows also seems to make no difference.
Antivirus
Our antivirus software shows no signs of having blocked anything, neither with popup messages nor in logs, so it does not seem to be the problem (but my gut feeling has not ruled that out completely). I cannot turn off antivirus software even momentarily, unfortunately, so I cannot test this myself.
Reliability history
The "View reliability history" report in Windows does not show anything abnormal related to the debugger or to the times when I've tried to use the debugger.
Observation by Embarcadero support
This observation by Embarcadero support, comparing their debug log (top) with mine (bottom) and noting a significant difference, is interesting, but what do with it? The "why" is a mystery.
This is from a DBK log on my system, you can see debugger is calling CreateProcessW (with DEBUG flags), the debugging thread then gets notified that the debugging session has start with this CREATE_PROCESS_EVENT
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[8680: 51565 ] CreateProcessW RC 1 osPid 2936 [CL=00000000]
[8680: 51565 ] setOSProcId(DbkProcId_t 1) -> 2936 0xb78 [CL=00000000]
[8680: 51565 ] leave:] W64PCntrlSrv::dispatch(START_PROC-1) [CL=00000200]
[8680: 51565 ] leave:] waitForCmdOrEvent [CL=00000200]
[7336: 51565 ] XX readn ->1312 [CL=00000000]
[8680: 51565 ] [start: waitForCmdOrEvent [CL=00000200]
[7336: 51565 ] leave:] doCmd(START_PROC-1) [CL=00000200]
[7336: 51565 ] leave:] cmdStartProc C:\Work\SalesForce\1021668\Win64\Debug\Project2.exe launch (null) cwd C:\Work\SalesForce\1021668\Win64\Debug\ [CL=00000200]
[8680: 51565 ] eventWait new Ev code 0000000000000003 [CL=00000000]
[7336: 51565 ] W64Proc::init() -> 1 [CL=00000000]
[8680: 51565 ] queing CREATE_PROCESS_EVENT(3) pId 2936 tId 7296 [CL=00000000]
[7336: 51565 ] leave:] W64Proc::init path "C:\Work\SalesForce\1021668\Win64\Debug\Project2.exe" args "" launcherPath (null) [CL=00000200]
[8680: 51565 ] [start: findThreadByOSTid( 7296 ) [CL=00000200]
[7336: 51565 ] <-API] IDbk::createProcess [CL=00000220]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now in your DBK log
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[5768: 7022 ] CreateProcessW RC 1 osPid 18444 [CL=00000000]
[5768: 7022 ] setOSProcId(DbkProcId_t 1) -> 18444 0x480c [CL=00000000]
[5768: 7022 ] leave:] W64PCntrlSrv::dispatch(START_PROC-1) [CL=00000200]
[5768: 7022 ] leave:] waitForCmdOrEvent [CL=00000200]
[5768: 7022 ] [start: waitForCmdOrEvent [CL=00000200]
[12780: 7022 ] XX readn ->1312 [CL=00000000]
[12780: 7022 ] leave:] doCmd(START_PROC-1) [CL=00000200]
[5768: 7022 ] eventWait new Ev code 0000000000000001 [CL=00000000]
[12780: 7022 ] leave:] cmdStartProc C:\Users\matthias.AARO\OneDrive - AARO Systems AB\Dokument\Embarcadero\Studio\Projects\64-bit debug test\Win64\Debug\Test64bit.exe launch (null) cwd C:\Users\matthias.AARO\OneDrive - AARO Systems AB\Dokument\Embarcadero\Studio\Projects\64-bi [CL=00000200]
[5768: 7022 ] cmd incoming [CL=00000000]
[12780: 7022 ] W64Proc::init() -> 1 [CL=00000000]
[5768: 7022 ] [start: W64PCntrlSrv::readCmd [CL=00000200]
[12780: 7022 ] leave:] W64Proc::init path "C:\Users\matthias.AARO\OneDrive - AARO Systems AB\Dokument\Embarcadero\Studio\Projects\64-bit debug test\Win64\Debug\Test64bit.exe" args "" launcherPath (null) [CL=00000200]
[12780: 7022 ] <-API] IDbk::createProcess [CL=00000220] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As you can see debugger does not see the normal CREATE_PROCESS_EVENT being fired by OS at all? So something is preventing the OS from generating the notification. It looks like debugee is launched but the debugger does not know it.