I am using Delphi 7 pro and debugging an older ISAPI app with IIS 7.5 (Windows 7).
Everything works fine except that if I place my cursor over a property to see the current value, sometimes Delphi will just display "evaluating" and hang - the only thing I can do at this point is reset the program.
Does anyone know if there is a setting I can adjust to prevent this hanging?
Check these settings:
Is the ISAPI dll running in a separate dedicated Application Pool?
Is "Maximum Worker Processes" set to 1?
Is the "Identity" set to a normal user, preferably your own account or the account you run the Delphi debugger with?
(If the ISAPI dll is 32-bit running on a 64-bit server: Is "Enable 32-bits applications" set to "True"?)
Are limits, timeouts and intervals set high enough or disabled so IIS won't try to recycle the worker process while you're debugging.
Related
Is there a way to force a Delphi application to always start on a particular desktop in Windows 10? I'm using multiple desktops, and sometimes switch between them when waiting for the application to compile. This has the effect that when it's finished compiling, the application is launched on the currently active desktop, i.e. not necessarily the "main" one where the IDE is placed.
It would be nice if there was a way to force Delphi to always use the main desktop when launching applications. Or if that's not possible in the IDE, could I at least force the application itself to always use the main desktop?
Note that I'm not talking about multiple monitors, but multiple Windows 10 Desktops.
I have been using Delphi to write and debug Service Applications for years. I am aware that I must start Delphi with "Run as Administrator" to "Attach to" and debug Service Apps. Until recently this has always worked.
Recently Delphi has stopped listing “System Processes” in the “Running processes” list. This circumstance is true for all installed versions of Delphi (10.2, XE8 & D2007). I am able to see system process from Visual Studio.
My Services are all 32bit Apps – though I don’t thing it matters, as I cannot see any system processes.
Another potential clue is that Delphi only sees 32bit Apps running in the current (desktop) session, regardless of Target Platform settings in the project.
I suspect that something may have changed in my OS (Windows 10 Pro Version 10.0.17134 Build 17134 ) or Security Settings or something… I have tried disabling Virus SW (Webroot SecureAnywhere) nothing seems to make any difference.
While this is not a total solution it does serve as a work-around:
It appears that the “Attach to process” dialog will not show System processes until I actually attach to something. This behavior has been repeatable.
Start the Delphi IDE with “Run as administrator”. Choose “Attach to Process” from the “Run” menu. I notice that only the current Session Processes are visible.
I “Attach” to any item on the list, it does not matter which one. Then I choose “Detach from Program” from the “Run” menu.
Next, I choose “Attach to Process” again and now all of the processes, including System Processes, are visible.
Another interesting note, is that Checking or Unchecking the “Show system processes” makes no difference before or after the initial “Attach”.
System Processes will now be visible anytime I choose “Attach to Process” from the “Run” Menu as long as the IDE is running. If I close and restart the IDE with the “Run as administrator” option, the System Processes are hidden until I attach/detach again.
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 CodeSite Express, bundled with Delphi XE Enterprise. Right now I'm developing an ISAPI application in XE (I trace and debug using attach to process in XE - works fine) and I'd like to get some CodeSite messages out of my ISAPI application.
In Advanced Techniques in the included CodeSite help, I found this:
"Logging From Services
Service applications run in a separate window station from that of the desktop. However, by default, the CodeSite Dispatcher runs in the desktop window station. As a result, the default message transport mechanism used to transfer CodeSite messages to the Dispatcher, the wm_CopyData window message, is blocked by Windows. Microsoft Windows does not allow window messages to cross window station boundaries..... Therefore, if we wish to send CodeSite messages from a service application to the Dispatcher, we need to connect to the Dispatcher using the TCP protocol instead of CopyData."
Question:
Am I corrent in assuming that the same rules are applicable to ISAPI applications? That I have to use TCP to get CodeSite messages out of ISAPI apps?
Given the fact that the ISAPI is loaded from IIS and IIS is running as a service, yes.
In the default configuration, yes. But there's more.
I'm not sure about newer versions, but in IIS 6, when you select isolation level high, your ISAPI dll is run from a dllhost.exe process over COM+. With the Components Services administration tool (formerly known as DCOM config) you can change the 'activation' configuration to use the currently logged on user, and the dllhost.exe instance will run in the active window station. (You can even start dllhost.exe as a host application to the Delphi debugger, with the /ProcessID:{} parameter and a guid of the COM+ entry)
What I've seen so far in IIS 7, is that w3wp.exe now loads and runs ISAPI dll's, but I'm not sure if something like the above applies. You may check if application pool settings have a similar activation setting.
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.