DLLHOST.EXE Errors & "Ajax"

[Don Miller]

I've been extensively modifying a web application (ASP, COM+) to take
advantage of the XMLHTTP object for asynchronous requests (e.g. Ajax) on my
dev machine (Win2KPro). I test the application from another machine on the
network (or using IE, Firefox, etc. on the same machine). Everything seems
to work fine (no errors anywhere) and the web application is snappy as
intended. However, at the end of the day when I turn off my dev machine,
many hours sometimes after I test the web app, right before it shut downs I
get an error message about DLLHOST.EXE, something about an attempt to
address something with the address location listed in hex. I don't get much
time to read it before it shuts down. And about half the time when I get
this error the night before, the hard disk is checked for data integrity the
next morning on boot-up.

I'm reluctant to move this web application to a production server with
something going wrong consistently with DLLHOST.EXE and these asynchronous
requests (that seem to be completed each time). I've checked the system
error logs and they don't show anything specific to DLLHOST at the time of
shutdown or any time else.

Can someone educate me as to what these errors mean? And how to find out
what is going on so I can fix it? Thanks.

 

[Mark Schupp]

Try running IISRESET and see if you get the same error message (it may stay
around longer).

Do you have any custom components in use?

Are you setting the intrinsic objects (request, response, etc) into local
variables? If so set them to nothing before the page or component method
ends.

 

[Don Miller]

Try running IISRESET and see if you get the same error message (it may
stay

around longer).

Good idea. Would I have to use the command line or can I reset IIS with the
IIS tools (Restart IIS...)

Do you have any custom components in use?

About 20, and one third-party component. They've all been in use for about 5
years without this particular error. I'm moving the new stuff (ajax) to
another Win2K machine and see if the error pops up again. But the fact that
it only shows up when I shut down puzzles me.

Are you setting the intrinsic objects (request, response, etc) into local
variables? If so set them to nothing before the page or component method
ends.

I haven't put any objects at all into local variables (I thought that was a
generally bad thing to do)

Thanks for the help.

 

[Don Miller]

Try running IISRESET and see if you get the same error message (it may stay
around longer).

I reset IIS manually and the DLLHOST error message did come up! I tried
pressing the No button to debug but nothing happened.

Does this mean anything to anybody? It certainly seems that this is related
to IIS now.

 

[Don Miller]

Here's more information that I'm hoping someone will know about. When I
restarted IIS, now I got an application popup message in Event Viewer that
has the text of the DLLHOST error message I get:

Application popup: dllhost.exe - Application Error : The instruction at
"0x779db683" referenced memory at "0x749f18e8". The memory could not be
"read".

Click on OK to terminate the program
Click on CANCEL to debug the program

Would this kind of error have anything to do with my programming?

 

[Mark Schupp]

Don,

We had similar errors with our application for a long time (they were
considered a "nuisance" and not a reason for concern). We finally had time
to track them down. In our case they were caused by setting the intrinsic
objects (request, response, etc) into global variables within our custom
DLLs so that internal code would have access to them. The problem was fixed
by setting the variables to "nothing" in the Class_Terminate() method of the
DLL (VB dlls). IIRC the problem did not show up until one of the Windows
2000 service packs.

 

[Don Miller]

Thanks for the tip. I do set instrinsic objects to local variables (not
global) in my VB dlls and set them to nothing for the last five years. I'll
have to look again at any new code (that I can't think of when I used these
objects). Haven't done a service pack in a while - just those monthly
updates from MS.

 

[Don Miller]

Thanks again Mark. After using the DebuDiag tool from MS and with help from
a MS support person in the IIS newsgroup, this was exactly the cause of the
issue. Apparently this bug (that was addressed in SP4) affected local
intrinsic objects as well (although the "bug" did enforce good programming
practices).

 

[Don Miller]

So, after installing SP4 and all rollups and setting all instrinsic ASP
objects to nothing in my COM+ object, the problem recurred. Any more
thoughts?