Pressing F12 while the program is running in the debugger should break the execution and open the debugger. This works correctly on Windows XP (tested with D2007 and XE2) but fails on Windows 7 and 8 (also tested with D2007 and XE2; tested on three computers).
Registry is set up properly (Windows 7):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"UserDebuggerHotKey"=dword:00000000
"Debugger"="\"C:\Windows\system32\vsjitdebugger.exe\" -p %ld -e %ld"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\AutoExclusionList]
"DWM.exe"=dword:00000001
The XP installation also sets "Auto"="1" and omits the AutoExclusionList but duplicating those changes on the Windows 7 machine accomplishes nothing.
The weird thing is that Delphi seems to be aware of the F12 being pressed. When I run a program in a debugger on a Windows 7 machine and press F12, Event Log window in Delphi shows
Thread Start: Thread ID: 4080. Process Project73.exe (7108)
Thread Exit: Thread ID: 4080. Process Project73.exe (7108)
It's just that the breakpoint is not triggered and application keeps running.
Does anybody know how to restore this functionality in Windows 7/8?
The Debugger sees that a new thread is started by Windows, but it doesn't know what that thread is. In XP this thread runs into a int 3 break point (DebugBreak()), but under Vista and Windows 7+ the breakpoint isn't hit anymore even if you set the registry key.
There exists a Delphi IDE plugin that catches the thread and calls the DebugBreak() WinAPI function.
http://andy.jgknet.de/blog/ide-tools/unsupported-tools/
Related
I updated my Windows 10 from 16179 to 16184 and since then, the Delphi ide does not appear anymore, but bds.exe is running normal in task manager.
Anybody has any clue whats going on?
Delphi is the only application so far which does not start properly.
When I revert back to 16179, Delphi works again as usual.
I am writing a COM+ component in Delphi 2009 on Windows 8. (I will move on to XE3 soon but for now it's D2009).
I have had quite a few IDE freezes when debugging regular simple forms applicaitions, mainly when closing the application after having stopped in a breakpoint and continued running the following code, but other than that D2009 works fine.
Now, the problem I have is that I am unable to debug the COM+ component. A new instance of this component is created from another forms application. If I specify that form applicaition in the "Run" options dialog of the project, it all works fine but no stop at the breakpoints in the COM+ object. I then found online about the way to debug by putting dllhost.exe in "run" with "/ProcessID: GUID" in the parameters. I double checked everything and all I see when I hit F9 is "Thread entered" then "Thread exited" in the debug console. Still not stopping at any breakpoints which all show up as out of running scope.
How can I do it then please ?
Thanks !
Check your components COM+ configuration. To correctly debug need Pool Size = 1 (Pooling & Recycling) and the component identity in "interactive user"
Scenario:
Delphi ISAPI dll written using Delphi XE, 32 Bit.
ISAPI dll is running through IIS 7.5 on a Win 7 64 enterprise desktop
machine.
DLL runs fine.
Debug the ISAPI DLL in the Delphi XE IDE by using Run->Attach to
Process:
Launch the ISAPI DLL and attach to the wpw3.exe *32 process in the
debugger - can trace and debug code as it runs in the ISAPI context.
Problem:
My hard drive died last week and I got a new Win 7 installation - the
standard corporate wide Win 7 64 Enterprise image (not the same as my
previous Win 7 64 installation).
Now, when I go into Run->Attach to Process, I no longer see the
wpw3.exe *32 process by name, although it is visible in task manager
by name. Invoking the 'show system processes' option on the 'Attach to
Process' Dialog box does not help.
What I DO see now (which I never saw before in my old deployment) is
a long list of 'generic' System process with PID's but no
descriptions other than 'System'.
One of these processes is my wpw3.exe *32 process, and I have identified
its PID using MS's Process Explorer. But if I try to attach to
that process I get an error message - 'Cannot create process -
access denied' - so I can't debug. (Same error message 'Error
Opening process, Access denied' also shows in Process Explorer for
certain properties, although the descriptive name of the process '
wpw3.exe *32' is visible there, associated with the PID.)
How can I get the Run->Attach to process dialog box to display the
proper wpw3.exe *32 process name and attach to it, so I can debug?
Is this a Delphi problem? An IIS problem? An ISAPI problem? Is this one problem - ie lack of descriptive process name and inability to attach to process are caused by same problem; or is this two problems: one problem being lack of descriptive name, another the inability to attach to the process?
(Do not want to use - cannot really use - webApp debugger for this -
these are ISAPI dll's that are deployed to production exactly as they
are written and debugged in IIS - I need to see them running in IIS
context.)
Been debugging ISAPI dll's for several years this way, with different versions of Delphi and in various OS and server environments without any problems - never encountered this problem before. I am stumped.
My account has admin rights, but it hit me that I should try running DelphiXE as an admin – launch it with the ‘run as administrator’ option.
I got prompted ‘do you want to allow…’ – clicked yes and Delphi ran. Set up my process and hooked in and traced through my code - process names now visible and I can attach to my IIS process and debug in the Delphi Debugger.
I did not have to go through this step in my previous deployment, for whatever reason - but problem solved.
If you want to debug a 32 bit ISAPI dll on a 64 bit OS you can use the following process.
This assumes that you have followed other steps to allow 32 bit ISAPI dlls to work.
Stop IIS
net stop w3svc
Start the 32 bit worker process in debug mode
%SYSTEMROOT%\SysWOW64\inetsrv\w3wp -debug
Attach to the w3wp in the debugger. As you noted you need to be running Delphi with elevated privileges for this to work.
I have an application written by Delphi 7 and this application works fine in windows XP.
Now i has upgrade my pc to windows 7 and everythings works fine with this application except when i click the button which will execute the TOpenDialog and TSaveDialog then hangs.
Anyone have this problems when using delphi 7 in windows 7?
Most likely reason is an issue with COM. The Open/Save dialog needs to run in an STA COM apartment otherwise some shell extensions can lock up.
If you have anything in your application which initializes COM in a different mode for the main thread, lots of strange things can happen.
I am really stumped.
I am running delphi 2007 on vista. I have built many applications and run them in XP with no problem. This latest app had to make use of threads. I'm pretty sure my code is correct. It runs fine on Vista, but when I run it on XP (tried multiple PC's) my program seems to lag (both os's 32 bit, XP sp3 and Vista sp1, dotnet v2). Best example being if I unplug the serial port my coms will continue to run etc.
I was installing delphi on my xp machine, and ran my program while delphi was running. As in I ran it from the exe built in vista. It ran fine then. Close delphi, and the comport starts to lag again.
If I unplug and replug a flash drive, the coms catches up again.
I want to build the app on my xp based machine, but have like a million 3rd party components that makes it a real mission to setup.
Oh fyi, i built a simple application with just the main thread, and a comport thread. Same problem. All the comthread will do is fetch data off the comport. Not even display it, i used a serial port monitor in the background to check for the lag.
Any suggestions welcome.
OK quick edit: the XP pc is freshly built. I opened msn messenger, and the program runs fine. I'm obviously missing some setting...
If you're using Sleep in your threads (hence my comment/query to your question), you should use timeBeginPeriod to indicate your desired resolution. As you've already found out it doesn't matter where you call it; can be the main thread or even an entirely different application.
See this thread on embarcadero forums, and of course the documentation (remarks) on MSDN.
Are your OS installed on two diverse PC?
I guess one of your computer has a true dual-core processor (the one with XP), and the other (the one with Vista) has a one-core processor. Sometimes multi-threaded app reveals their problem when run on true multi-core processor.
The Delphi debugger sometimes change the CPU affinity, so it could work on the debugger, but not outside it.
Another possibility to check: try your software under XP with setting affinity to only one CPU.
I've seen that before. But it's likely something else, since you said you've tried your SW in multiple PCs.