Board index » delphi » double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.


2003-08-11 09:11:46 PM
delphi233
Hi.
I spent the last 4 weeks debugging an ISAPI application on a Win2K
server (I followed Colin's instructions on how to do that, and all was
well).
Now, the DLL works fine in Debug mode and I want to start testing the
site in regular mode. This is where the proverbial fly in the ointment
shows up.
I reversed the steps I had applied to be able to debug the app on the
server. But when trying to access the DLL from a browser, the server
beeps once. The browser on the other machine never gets anything back
and keeps running - the Windows 'flag' at the top right corner keeps
flapping. that is all.
I noticed that there are 2 copies of DLLHOST.EXE running on the server.
Is this normal?
I also checked URLScan.log and there are no problems there.
Has someone experienced this behaviour before?
I am really stuck.
Jean-Rene Nicolet
 
 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

jrnicolet (XXXX@XXXXX.COM) moved some electrons around and
created the following:
Quote
Hi Robert!
Thanks for the info.
However, I am not familiar with the tools you mention: filemon, tdimon
and regmon ...

Could you give me pointers (I tried Help, but with no success...)
www.sysinternals.com/
--
___________________________________________
Robert MacLean
robert at sadev dot co dot za
Web: www.sadev.co.za
 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

Hi Robert!
Thanks for the info.
However, I am not familiar with the tools you mention: filemon, tdimon
and regmon ...
Could you give me pointers (I tried Help, but with no success...)
Regards,
JRN
Robert MacLean writes:
Quote
jrnicolet (XXXX@XXXXX.COM) moved some electrons around and
created the following:

>Hi.
>
>I reversed the steps I had applied to be able to debug the app on the
>server. But when trying to access the DLL from a browser, the server
>beeps once. The browser on the other machine never gets anything back
>and keeps running - the Windows 'flag' at the top right corner keeps
>flapping. that is all.

This means that the client is waiting for the server to send data back. Could
mean a bug in the dll.
The beep sounds odd though.
What I suggest is get filemon and tdimon (and maybe regmon) and monitor the
file access and network traffic from the server.
Then also check the basics, "scripts and executables" set, iusr has
permissions on the dll and any files it might use etc....

>I noticed that there are 2 copies of DLLHOST.EXE running on the
>server. Is this normal?


yes

 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

Hi.
I used FileMon to look at accesses while trying to run my DLL from a
browser, and after 25 successful accesses (25 lines in the FileMon
output) to my DLL, DLLHOST.EXE fails to access 4 files I know nothing
about - with result "FILE NOT FOUND". Then a few lines after this, there
is a "BUFFER OVERFLOW" result while trying to access my DLL again.
(My App name is IMW.DLL)
The 4 files that DLLHOST failed to access are:
D:\inetpub\wwwroot\dll\imw.ENU
D:\inetpub\wwwroot\dll\imw.ENU.DLL
D:\inetpub\wwwroot\dll\imw.EN
D:\inetpub\wwwroot\dll\imw.EN.DLL
Is this normal behaviour? Am I missing something - again, nothing of the
sort happened during debug sessions...
Regards,
JRN
 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

XXXX@XXXXX.COM (XXXX@XXXXX.COM) moved some electrons around
and created the following:
Quote
Hi.

there is a "BUFFER OVERFLOW" result while trying to access my DLL
again. (My App name is IMW.DLL)
buffer overflow's are normal most of the time in filemon.

The 4 files that DLLHOST failed to access are:

D:\inetpub\wwwroot\dll\imw.ENU
D:\inetpub\wwwroot\dll\imw.ENU.DLL
D:\inetpub\wwwroot\dll\imw.EN
D:\inetpub\wwwroot\dll\imw.EN.DLL
do those files exist?
Quote
Is this normal behaviour? Am I missing something - again, nothing of
the sort happened during debug sessions...
i must admit the files not found seems off.
the en and enu make me think of languages.
--
___________________________________________
Robert MacLean
robert at sadev dot co dot za
Web: www.sadev.co.za
 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

No, the files do not exist - and this behaviour happens every single
time. I tried rebooting the server. No good.
I also did a global search in my app (Find in files...) and found no match.
I looked at the various processes running on the server. I found that
after the second attempt by a browser to access my DLL, DLLHOST.EXE
takes up 99% of the CPU...
Regarding the Buffer Overflow, I thought that it was pertaining to my
DLL's activity, not FileMon itself. One learns every day!
The ironic part is that it took me the longest time to set the server up
to work for debugging! And now that the App is ready for pre-prod tests,
no go! Very frustrating. And I have a looming deadline...
I guess I am just stuck at this point.
Cheers,
Jean-Rene
Robert MacLean writes:
Quote
XXXX@XXXXX.COM (XXXX@XXXXX.COM) moved some electrons around
and created the following:

>Hi.
>
>there is a "BUFFER OVERFLOW" result while trying to access my DLL
>again. (My App name is IMW.DLL)

buffer overflow's are normal most of the time in filemon.

>The 4 files that DLLHOST failed to access are:
>
>D:\inetpub\wwwroot\dll\imw.ENU
>D:\inetpub\wwwroot\dll\imw.ENU.DLL
>D:\inetpub\wwwroot\dll\imw.EN
>D:\inetpub\wwwroot\dll\imw.EN.DLL


do those files exist?


>Is this normal behaviour? Am I missing something - again, nothing of
>the sort happened during debug sessions...

i must admit the files not found seems off.
the en and enu make me think of languages.
 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

jrnicolet (XXXX@XXXXX.COM) moved some electrons around and
created the following:
Quote
I looked at the various processes running on the server. I found that
after the second attempt by a browser to access my DLL, DLLHOST.EXE
takes up 99% of the CPU...
Does it stay at 99%?
Quote
Regarding the Buffer Overflow, I thought that it was pertaining to my
DLL's activity, not FileMon itself. One learns every day!
What I meant is that filemon picks up the buffer overflows on the file system
level. it is not with the dll.
Quote
The ironic part is that it took me the longest time to set the server
up to work for debugging! And now that the App is ready for pre-prod
tests, no go!
Is that the same server as you used for debugging?
--
___________________________________________
Robert MacLean
robert at sadev dot co dot za
Web: www.sadev.co.za
 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

Weird stuff happening:
I set everything for Debug mode (as described by Colin in his article).
When I hit F9 in Delphi, the webServer is stopped, eht IIS, FTP and WWW
services are manual and stopped.
Then I hit the web site from a browser (and I am expecting either a
message saying that the site is not up or the first breakpoint in Delphi
go get focus), and guess what: I get the home page, I can hit the DLL
and the DLL works file, all in straight mode - not a peep from Delphi,
even though I have set breakpoints and we are supposed to be in Debug
mode. Even better: None of the services listed above are running at all:
not WebService, not IIS, not FTP nor WWW...
Now I am lost.
JRN
My customer just told me they had a power surge last week while I was
away. Could it have corrupted something in the server? Should we have
the server hardware looked at?
 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

I suggest that you dont ever change a server to debug on the server. Debug
on your development machine . When you make changes to W2K , regardless of
what the docs say, you have to reboot before the changes take effect. Also,
purge all cached webpages from the machine that you are running on. Make
your develpment environment be like your server, not the other way around.
You may have to reinstall the OS to get it back like it was, particularly if
you are not familiar with the effects of the changes you just make to the
com objects on your server. Once you get it back, LEAVE IT ALONE . I have
been developing ISAPI for years and have never had to debug on the server.
Sometimes I change my connection string to point to a production DB on the
server, but that is not the same as debugging on the server. Good luck
 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

Thanks Del!
I will initiate an OS re-install and change the setup so that I can have
a development platform that is set up like the server which I will leave
untouched - as you recommend.
BTW - I managed to obtain an indication of what might be wrong: I got
the following message in the logfile (in logfile
C:\WINNT\system32\LogFiles\W3SVC1\nc030812.log):
Quote
>
(Server IP Address here)- - [12/Aug/2003:15:57:40 -0600] "GET
/dll/imw.dll?Out-of-process+ISAPI+extension+request+failed. HTTP/1.1"
503 274
<<
Regards,
Jean-Rene
Del Murray writes:
Quote
I suggest that you dont ever change a server to debug on the server. Debug
on your development machine . When you make changes to W2K , regardless of
what the docs say, you have to reboot before the changes take effect. Also,
purge all cached webpages from the machine that you are running on. Make
your develpment environment be like your server, not the other way around.
You may have to reinstall the OS to get it back like it was, particularly if
you are not familiar with the effects of the changes you just make to the
com objects on your server. Once you get it back, LEAVE IT ALONE . I have
been developing ISAPI for years and have never had to debug on the server.
Sometimes I change my connection string to point to a production DB on the
server, but that is not the same as debugging on the server. Good luck


 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

Just a thought...
I have an ISAPI routine that links in a 3rd party product (DCE/ENCINA in my
case) that only runs in debug mode. It turned out that this product makes a
low level Windows permission API call. The call fails when run on a
production IIS setup but works when run in debug mode. The only answer we
ever got was that the login context of IUSER_ has a different permission set
when run in debug mode, supposedly because the DLL is being run by a desktop
process and not an NT service???
Anyway, if this sounds like something you may have, I can tell you how we
worked around the problem. We had a short term solution that has now turned
into a long term solution. Not pretty but it works.
DaveH
"jrnicolet" <XXXX@XXXXX.COM>writes
Quote
Weird stuff happening:

I set everything for Debug mode (as described by Colin in his article).

When I hit F9 in Delphi, the webServer is stopped, eht IIS, FTP and WWW
services are manual and stopped.

Then I hit the web site from a browser (and I am expecting either a
message saying that the site is not up or the first breakpoint in Delphi
go get focus), and guess what: I get the home page, I can hit the DLL
and the DLL works file, all in straight mode - not a peep from Delphi,
even though I have set breakpoints and we are supposed to be in Debug
mode. Even better: None of the services listed above are running at all:
not WebService, not IIS, not FTP nor WWW...

Now I am lost.

JRN

My customer just told me they had a power surge last week while I was
away. Could it have corrupted something in the server? Should we have
the server hardware looked at?

 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

Hi Dave!
Actually, now that you mention it, we also have a 3rd party component
(VCLZIP) that seems to be working in debug mode. We may have a similar
situation.
Maybe it is something I should pursue...
Cheers,
Jean-Rene N
DaveH writes:
Quote
Just a thought...

I have an ISAPI routine that links in a 3rd party product (DCE/ENCINA in my
case) that only runs in debug mode. It turned out that this product makes a
low level Windows permission API call. The call fails when run on a
production IIS setup but works when run in debug mode. The only answer we
ever got was that the login context of IUSER_ has a different permission set
when run in debug mode, supposedly because the DLL is being run by a desktop
process and not an NT service???

Anyway, if this sounds like something you may have, I can tell you how we
worked around the problem. We had a short term solution that has now turned
into a long term solution. Not pretty but it works.

DaveH



"jrnicolet" <XXXX@XXXXX.COM>writes
news:XXXX@XXXXX.COM...

>Weird stuff happening:
>
>I set everything for Debug mode (as described by Colin in his article).
>
>When I hit F9 in Delphi, the webServer is stopped, eht IIS, FTP and WWW
>services are manual and stopped.
>
>Then I hit the web site from a browser (and I am expecting either a
>message saying that the site is not up or the first breakpoint in Delphi
>go get focus), and guess what: I get the home page, I can hit the DLL
>and the DLL works file, all in straight mode - not a peep from Delphi,
>even though I have set breakpoints and we are supposed to be in Debug
>mode. Even better: None of the services listed above are running at all:
>not WebService, not IIS, not FTP nor WWW...
>
>Now I am lost.
>
>JRN
>
>My customer just told me they had a power surge last week while I was
>away. Could it have corrupted something in the server? Should we have
>the server hardware looked at?
>



 

Re:double DLLHOST.EXE: Trouble with Win2K and Delphi Isapi App.

For the short term solution, we used Memproof to run IIS. The only problem
is that you need to log into the desktop and physically start Memproof
everytime the server is rebooted. Hopefully, you don't need to reboot very
often.
The long term solution was to create an NT service application and put the
3rd party code in it. Then have the ISAPI app communicate with it via
shared memory or sockets.
DaveH
"jrnicolet" <XXXX@XXXXX.COM>writes
Quote
Hi Dave!

Actually, now that you mention it, we also have a 3rd party component
(VCLZIP) that seems to be working in debug mode. We may have a similar
situation.
Maybe it is something I should pursue...

Cheers,
Jean-Rene N


DaveH writes:
>Just a thought...
>
>I have an ISAPI routine that links in a 3rd party product (DCE/ENCINA in
my
>case) that only runs in debug mode. It turned out that this product
makes a
>low level Windows permission API call. The call fails when run on a
>production IIS setup but works when run in debug mode. The only answer
we
>ever got was that the login context of IUSER_ has a different permission
set
>when run in debug mode, supposedly because the DLL is being run by a
desktop
>process and not an NT service???
>
>Anyway, if this sounds like something you may have, I can tell you how
we
>worked around the problem. We had a short term solution that has now
turned
>into a long term solution. Not pretty but it works.
>
>DaveH
>
>
>
>"jrnicolet" <XXXX@XXXXX.COM>writes
>news:XXXX@XXXXX.COM...
>
>>Weird stuff happening:
>>
>>I set everything for Debug mode (as described by Colin in his article).
>>
>>When I hit F9 in Delphi, the webServer is stopped, eht IIS, FTP and WWW
>>services are manual and stopped.
>>
>>Then I hit the web site from a browser (and I am expecting either a
>>message saying that the site is not up or the first breakpoint in Delphi
>>go get focus), and guess what: I get the home page, I can hit the DLL
>>and the DLL works file, all in straight mode - not a peep from Delphi,
>>even though I have set breakpoints and we are supposed to be in Debug
>>mode. Even better: None of the services listed above are running at all:
>>not WebService, not IIS, not FTP nor WWW...
>>
>>Now I am lost.
>>
>>JRN
>>
>>My customer just told me they had a power surge last week while I was
>>away. Could it have corrupted something in the server? Should we have
>>the server hardware looked at?
>>
>
>
>