I have Windows Server 2008 R2 Machine that is running a Delphi 2007 application. Update: Switching Delphi versions is currently not an option. I have Delphi XE but there are over 300,000 lines of code to review before any switch can occur.
I have run into a problem where I would like to step through the code. I don't want to install Delphi on the machine, so I have installed the remote debugger.
Updated steps to be more complete:
Compile app with Remote Debug Symbols
Copy Application and Remote Debug Symbols to Remote Location.
Launched an Command Prompt (Running As an Administrator) on the Remote Machine.
Enabled Server Firewall exception for rmtdbg105 process.
Run rmtdbg105 -listen in the Command Prompt
I run the process I want to debug.
On my local machine I select attach to process and select the remote process.
Press Attach
Behavior observed:
Remote Process locks up and stops running, and so does Delphi on my machine.
I have waited several minutes just in case it caused by some type of network performance problem.
Is there step I am missing? I am looking for a way to get this to work.
Move back to Delphi 7, or up to Delphi XE, and try again. [Moving up to XE might be a bit of work, because you need to port your sources up to unicode delphi language level.]
I never did get Delphi 2007 remote debug to work reliably. The freeze-ups you see are something I remember too, when I was using Delphi 2007. I found that it froze less often when the PC had been rebooted recently. After a reboot you might get a few more uses, before you need to reboot again.
Did you run the remote debugger from a privileged console? Also check the debugger files against those in Delphi bin directory, IIRC some files has been updated by a patch, but the remote debugger installer wasn't. Try to use the updated files as well.
Anyway the 2007 debugger has issue under 7 and I guess it may have as well under 2008 R2, there is an unsupported patch from Embarcadero site, try that too.
Related
Here's what happens:
Using a Macbook Pro, I use the Microsoft Remote Desktop Connection application to connect to my work computer, which is a Windows 10 machine
If I try to launch Spyder on my work computer, I get this error:
Load Library Error
However:
If I am at my work computer (i.e. physically at work instead of logging in remotely), I can launch Spyder successfully
If I leave Spyder open on my work computer, then go home and do a remote log-in to my work computer, I can use Spyder without issue. The problem/error described above arises only if I try to open Spyder through the remote connection.
This error only seems to affect Spyder and I can use all other programs without issue through a remote connection. As a workaround I've been using other IDEs and successfully running scripts, but I strongly prefer Spyder.
What I have tried so far (without success):
The 4 troubleshooting steps posted by Fazil M. to this Microsoft thread
Uninstalling/reinstalling Spyder using Conda
Restarting my work computer
System Information:
Work Computer OS: Windows 10, 64-bit
OS of computer through which I'm logging in to work computer: Mac OS X El Capitan 10.11.6
Spyder version: 4.1.1
Any thoughts as to what could be going on?
Update--More information and trials:
I checked out Issue #3736 on Spyder's GitHub. It says to download and add a file called opengl32sw.dll to the folder ~\Lib\site-packages\PyQt5\Qt\bin. But when I go to the PyQt5 folder, I do not see a subfolder for Qt. I tried placing it into the PyQt5 main folder, but that did not fix the problem.
I've heard this can be a graphics card issue too. On my machine I have two graphics cards: AMD RadeonT R5 430 and Intel(R) HD Graphics 630.
Darren's answer did not work for me. What did work was to:
First option: go into the device manager and disable the Intel HD Graphics card under "display adapters."
Second option:
run "Gpedit.msc"
navigate to Computer Configuration->Administrative
Templates->Windows Components->Remote Desktop Services->Remote
Desktop Session Host->Remote Session Environment
Disable "use WDDM graphics display driver for remote desktop
connections"
Restart the computer
See https://answers.microsoft.com/en-us/windows/forum/all/windows-10-1903-may-update-black-screen-with/23c8a740-0c79-4042-851e-9d98d0efb539
It took help from my organization's IT contractor, but I fixed the issue by doing the following:
Run a file called "gpedit.msc", which will open up a window for Local Group Policy Editor
In the tree menu on the left, navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment, and open the Remote Session Environment folder (not the subfolder within it)
Make sure the following are set to "Enabled":
"Use hardware graphics adapters for all Remote Desktop Services"
"Prioritize H.265/AVC444 graphics mode for Remote Desktop Connections"
"Configure H.264/AVC hardware encoding for Remote Desktop Connections"
Then restart the computer.
Since I was unable to get pass LoadLibrary 126 error using the solutions provided online and on here, I stepped back and realized the obvious workaround. The errors occurs when you open the program while you're using a remote session, right? The obvious solution is to launch the program while a remote session is not in progress. To do this while you're remoting, you should create a batch script to launch the program but make sure to include to a time delay before that (I used 'timeout 10 /nobreak' to do so). Run the batch script and, before your program launchs, disconnect from RDP. After enough time passes for the program to launch, you can reconnect to RDP and your program will be up and ready
I need to work with Delphi 6 Update 2 in Windows 8.1 x64 (in case you were wondering, it's about maintaining an old application, migrating to a newer version is not an option. I can't use a VM because I use the same machine to connect to some peripherals that don't work in a VM).
The problem is that Update 2 has a 32 bit installer with a 16 bit stub. So the current behaviour is that the installer starts, it extracts the files in a temp location, starts the setup then nothing appears on screen.
So far, I gathered that it is impossible to do it. But the same behaviour I 've seen for SQL Server 2000 (don't ask) but there I was able to use msetup.exe (DemoShield) to open a sqlservr.dbd that started the script. However, there is no such dbd file. I guess I was lucky on SQLServer 2000.
So far I've tried compatibility mode, DosBox, replacing the setup file with both Installshield 3 and 5, waiting for hours for the setup to start (sometimes, W8 does that), even comparing files and registries on an XP machine before and after update 2 but this might be a bit too risky to apply on a real machine.
Since Windows 8.1 86 includes Hyper-V for running VMs, most modern hardware supports Hyper-V, and Windows 8 x86 can still run 16-bit based apps:
Install a Windows 8.1 x86 VM under your host physical machine, then install it there.
The up-tick: it is easy to move your VM to a new host without needing to reinstall a full new VM.
See http://www.techrepublic.com/blog/windows-and-office/get-started-with-windows-8-client-hyper-v-the-right-way/7893/ and http://www.infoworld.com/d/virtualization/5-excellent-uses-of-windows-8-hyper-v-208436 to get started with Hyper-V.
Hyper-V can redirect quite a bit of hardware from the host to the VM nowadays. For "old" hardware like COM and LPT ports you often can buy USB adapters that can be redirected.
If installing on x86 Windows 8.1 works and x64 fails, I think you have proved the assumption that the 16-bit portion of the installer is the culprit.
Maybe my blog post from last year can solve your problem:
http://blog.dummzeuch.de/2013/11/11/delphi-6-on-windows-8-1/
excerpt:
I just deleted the registry entry
HKCU\Software\Borland\Delphi\6.0\LM
(I did not make a backup, what would have been the point?)
I started Delphi 6, ignored the warning about incompatibilities (which was talking about Delphi 7 anyway) and went through the registration/activation process again. This time it worked.
Maybe I should mention, that I did not install any of my Delphi versions to c:\program files but put them into c:\Delphi instead to avoid any problems with access rights to the installation directory.
My company runs an old application written in delphi. A simple com server which serves some database for some computers. I have to run the server once in every computer to register the com interfaces and it have been working since the ancient days of whatever in windows xp.
Using windows xp I have never had a single problem but in windows seven the class just won't register and no matter what I try(I tried exporting the register keys) when I open the client I will still get the error "Class not registered".
Any advice? Plz save my Christmas.
My COM servers, both EXEs and DLLs, are written in BCB6 (as opposed to Delphi) on 32-bit XP and they work just fine when installed on 64-bit Windows 7. You just have to make sure that you run their installation code from an elevated process, that's all. Open an instance of cmd.exe with the "Run as administrator" option, then navigate to your COM server's folder and run it with the /INSTALL parameter (for EXEs) or the 32-bit version of regsvr32.exe (for DLLs) from the WOW64 system folder.
I have a .NET windows service that is calling cdb.exe to analyze crash dumps. I want to download the symbols from http://msdl.microsoft.com automatically when needed, using the argument:
-y srv*c:\symbols*http://msdl.microsoft.com/download/symbols
If I run the application as a console application, It works as expected and it downloads the needed symbols for each dump.
The problem is when I start the app as a windows service, the symbols are not downloaded and, if I turn symnoisy on, at cdb's output log I have an entry for each symbol saying that the symbol hasn't been found at http://msdl.microsoft.com
So, I've checked it using a sniffer and the funny thing is that no request is made to the microsoft symbols server when running as a service.
Googling a little, I've found that I'm not the only one with this issue and it seems that the problem is that when running an application as a windows service, it is using winHTTP library for http requests, instead of wininet, which I think is the root of the problem: http://support.microsoft.com/kb/238425
So, I don't know why, cdb is not able to connect to ms symbols server using winHTTP library and I need a way to force cdb use wininet by default.
Anyone has an idea of a workaround to this issue?
Full answer here: https://web.archive.org/web/20150221111112/http://infopurge.tumblr.com/post/10438913681/how-does-cdb-access-the-microsoft-symbol-server
When running from a Command Prompt, cdb uses WinINet to access internet resources. When running from a Windows service, cdb uses WinHTTP to access internet resources.
For WinHTTP you need to set some registry settings to stop an attempt to use a proxy (bogusproxy) for accessing the symbol server.
You can force cdb to use WinHttp from a command line, and thus emulate what is happening within the service for test purposes by typing the following before loading cdb.
SET DBGHELP_WINHTTP=AnythingOtherThanEmpty
To disable the WinHTTP proxy for cdb and symsrv you need to set the one of the following keys in the registry.
For x32 version of cdb running on a x32 bit machine from the Windows Service environment.
HKLM\Software\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
For x32 version of cdb running on a x32 bit machine from a Command Prompt.
HKEY_CURRENT_USER\Software\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
For x32 version of cdb running on a x64 bit machine from the Windows Service environment.
HKLM\Software\Wow6432Node\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
For x32 version of cdb running on a x64 bit machine from a Command Prompt.
HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
For x64 version of cdb running on a x64 bit machine from the Windows Service environment.
HKLM\Software\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
For x64 version of cdb running on a x64 bit machine from a Command Prompt.
HKEY_CURRENT_USER\Software\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
You can also do the opposite - force dbghelp.dll to use WinInet instead of WinHTTP by adding
DBGHELP_WININET=1
to the system environment. It will fix the issue in cdb.exe and other tools that use dbghelp.dll, symchk.exe for example.
The same issue arises when running from the Task Scheduler.
I've tried using different accounts, to no avail, until I found this post.
I'm launching CDB from a python script (that performs all the 'magic' in getting the right prerequisites in place) and to ease the launch of python I've created a small batch script.
Adding the environment variable as described by sekogan solved the issue.
#echo off
setlocal
REM Forcing CDB to use WinInet instead of WinHTTP when running as a
REM 'service' due to that WinHTTP uses some bogus proxy when not run from
REM the console.
set DBGHELP_WININET=1
set PYTHONPATH=<your path>
call <path to venv>\Scripts\python.exe -m <script module> <params>
endlocal
I followed these instructions while trying to get remote debugging working with Delphi 2007. After completing all the steps, the remote debugger is half working.
It is able to launch and halt the application but the break points I set do not work. The automatic break point (at line Application.Initialize;) is working but it goes right to the CPU window. The debugging information appears to be missing.
I triple checked, both 'Include TD32 debug info' and 'Include remote debug symbols' are checked, a clean build was performed, and the correct files have been moved to the remote machine.
What am I missing?
Any help would be greatly appreciated.
You might like to go through my own checkist for this, which is as follows. I hope its not too patronising, but there may be a step you've omitted. I also seem to recall that it was improtant to use IP addresses, not names. Also note that these instructions are for D7, howver I'm not aware that the principle has changed.
=======
In this description, TARGET refers to the machine being debugged (i.e the remote machine) and HOST refers to the machine being used fro debugging (i.e the local machine).
If necessary, install the remote debugger on the target by copying the RDEBUG folder to the target and running SETUP.
Run the remote debugger locally on the target using Start | Borland Remote Debugger | Remote debugger. A ‘spider’ icon should appear in the task bar. (It can be useful to double-click on this icon to obtain a connection status dialog – this shows how the local IDE is connecting to the remote in later steps here).
On the host machine, explode the project to be debugged. Check that this compiles locally and runs offline.
By convention, copy the SOFTWARE ROOT folder from the host to the target. This will be the working folder for the application when debugged. By copying the folder in its entirety, all support files will be found locally as needed. (This also fits nicely with using SecondCopy to duplicate the entire ART software tree on a remote machine and then to explode the required project – this will create the remote folder for you).
In the Delphi IDE on the local machine, use Run | Parameters | Remote to set the Remote Path to the remote exe file in the folder you have just copied, as it will be visible on the target machine. If you’ve copied it as instructed in ‘4’, this path will be identical to the file that the local IDE would create and debug, eg “C:\Art_Soft\RT290\Bench\Dev4all\RT290w.exe”
In the Delphi IDE on the local machine, use Run | Parameters | Remote to set Remote Host to the IP address of the target (you should use IPCONFIG on the target to find out what the IP address is). Before leaving the dialog, select ‘Debug Project On Remote Machine’.
Enable “Include remote debug symbols” on the “EXE and DLL options” pane under Project|Options|Linker
Compile and run the file from the IDE. The remote connection status should show connection progress and a the remote screen should show the application running.
What are the correct files? I assume both the .exe and .rsm file?
(disclaimer: I only know remote debugging in D2009)