Remote Debugging with CDB chooses wrong Bit version
-
So I'm trying to remote debug my msvc2019 32Bit compiled application, but the process always stalls at this point.
On the local machine:t 10:41:11.749 cdb: Reading initial command '.idle_cmd !qtcreatorcdbext.idle' t 10:41:11.749 Execute when idle: !qtcreatorcdbext.idleOn the remote machine:
I assume that its due to the wrong cdb bit version being used by the local machine to start the remote debug session as it states the following in the debug output:
t10:41:11.646 [15ms] dStart parameters: '' mode: 6 dABI: x86-windows-msvc2019-pe-64bit dLanguages: c++ dDebugger: C:\Program Files\Windows Kits\10\Debuggers\x64\cdb.exe dProject: C:\Program Files\Windows Kits\10\Debuggers\x64 dAdditional Search Directories: dRemote: tcp:server=169.254.191.180,port=1234 dSysroot: dDebug Source Location: /usr/src/debug/qt5base/src/corelib:/usr/src/debug/qt5base/src/gui:/usr/src/debug/qt5base/src/networkIt somehow always uses the 64bit Abi and x64\cdb.exe although my Kit is properly configured to be x86 explicitly. If I run the debugger locally, it manages to use the correct configuration:
t10:51:39.840 [25ms] dStart parameters: 'MyProgram' mode: 1 dABI: x86-windows-msvc2019-pe-32bit dLanguages: c++ dExecutable: C:\Users\Documents\MyProgram\build-MyProgram-Desktop_Qt_5_15_2_MSVC2019_32bit-Debug\debug\MyProgram.exe dDirectory: C:\Users\Documents\MyProgram\build-MyProgram-Desktop_Qt_5_15_2_MSVC2019_32bit-Debug dDebugger: C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe dProject: C:\Users\Documents\MyProgram dAdditional Search Directories: dSysroot: dDebug Source Location: /usr/src/debug/qt5base/src/corelib:/usr/src/debug/qt5base/src/gui:/usr/src/debug/qt5base/src/networkI tried removing the .pro.user file with no change in behavior.
This is my Kit
The remote machine is based on win7 sp1 and has both cdb bit versions installed. Because it is Win7 it uses an older cbd version 6.12.0002.633. Whereas the local machine uses Win10 and cdb version 10.0.17763.132. Should the version mismatch be a problem here? I cant get the Win10 cdb debugger to run on the remote machine. I already tried several redistributables/universal c runtimes, but theres always some dll missing.
All of which leads me to believe that the main problem is, that the qtcreators start remote debug session is using the wrong bitness!
-
So I'm trying to remote debug my msvc2019 32Bit compiled application, but the process always stalls at this point.
On the local machine:t 10:41:11.749 cdb: Reading initial command '.idle_cmd !qtcreatorcdbext.idle' t 10:41:11.749 Execute when idle: !qtcreatorcdbext.idleOn the remote machine:
I assume that its due to the wrong cdb bit version being used by the local machine to start the remote debug session as it states the following in the debug output:
t10:41:11.646 [15ms] dStart parameters: '' mode: 6 dABI: x86-windows-msvc2019-pe-64bit dLanguages: c++ dDebugger: C:\Program Files\Windows Kits\10\Debuggers\x64\cdb.exe dProject: C:\Program Files\Windows Kits\10\Debuggers\x64 dAdditional Search Directories: dRemote: tcp:server=169.254.191.180,port=1234 dSysroot: dDebug Source Location: /usr/src/debug/qt5base/src/corelib:/usr/src/debug/qt5base/src/gui:/usr/src/debug/qt5base/src/networkIt somehow always uses the 64bit Abi and x64\cdb.exe although my Kit is properly configured to be x86 explicitly. If I run the debugger locally, it manages to use the correct configuration:
t10:51:39.840 [25ms] dStart parameters: 'MyProgram' mode: 1 dABI: x86-windows-msvc2019-pe-32bit dLanguages: c++ dExecutable: C:\Users\Documents\MyProgram\build-MyProgram-Desktop_Qt_5_15_2_MSVC2019_32bit-Debug\debug\MyProgram.exe dDirectory: C:\Users\Documents\MyProgram\build-MyProgram-Desktop_Qt_5_15_2_MSVC2019_32bit-Debug dDebugger: C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe dProject: C:\Users\Documents\MyProgram dAdditional Search Directories: dSysroot: dDebug Source Location: /usr/src/debug/qt5base/src/corelib:/usr/src/debug/qt5base/src/gui:/usr/src/debug/qt5base/src/networkI tried removing the .pro.user file with no change in behavior.
This is my Kit
The remote machine is based on win7 sp1 and has both cdb bit versions installed. Because it is Win7 it uses an older cbd version 6.12.0002.633. Whereas the local machine uses Win10 and cdb version 10.0.17763.132. Should the version mismatch be a problem here? I cant get the Win10 cdb debugger to run on the remote machine. I already tried several redistributables/universal c runtimes, but theres always some dll missing.
All of which leads me to believe that the main problem is, that the qtcreators start remote debug session is using the wrong bitness!
@InTheBeninging said in Remote Debugging with CDB chooses wrong Bit version:
169.254.191.180
I'm just wondering that your remote host has this kind of IP (
169.254.X.X).
In what net your debugger (debugging machine) is located?!169.254.X.Xmeans that your DHCP failed.
Are you able to connect to it at all?
If debugging is the process of removing software bugs, then programming must be the process of putting them in.
~E. W. Dijkstra
-
@InTheBeninging said in Remote Debugging with CDB chooses wrong Bit version:
169.254.191.180
I'm just wondering that your remote host has this kind of IP (
169.254.X.X).
In what net your debugger (debugging machine) is located?!169.254.X.Xmeans that your DHCP failed.
Are you able to connect to it at all?@Pl45m4 I connected the remote pc via an ethernet cable. The console output from the first image also only appears when i hit start remote debug on the local qtcreator machine and im able to ping the remote pc, so there should be a connection. I even tried enabling the firewall for cdb. Still no change in behavior.
I get the same result when I use remote debug via COM Port. -
Whats also odd is that in the debug output it says
dStart parameters: '' mode: 6 ... dProject: C:\Program Files\Windows Kits\10\Debuggers\x64In Start parameters should actually be my applications name and in Project the path of the executable instead of the debugger. In the example of the local debug session the values are set correctly. This seems to be a bug, i guess?
