David
Sun Jan 23 20:03:10 CST 2005
Yes, the VB Runtime hack was done so that you do not need to recompile the
DLL for RIM/UE issues.
If it continues to crash, IIS State is the next step to catch the crash.
http://www.iisfaq.com/default.aspx?view=P197
However, I must warn you to not get your hopes up -- the hoops we are
jumping through allows VB code written to work on a server to function --
very different than trying to make VB code NOT written to work on a server
to function. It is highly likely that regardless of the settings/binaries
on the server, your 3rd party control simply will not reliably run on a
server. As I had noted earlier, client-side and server-side coding is very
different, so it is highly unlikely for you to lift that code, install it on
a server, and expect it to magically work.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Ken" <Ken@discussions.microsoft.com> wrote in message
news:AC69EFB0-296E-4449-BE59-A5D247E3D7B6@microsoft.com...
David,
Thanks for the info. Another kb articles indicates that W2000 SP4 contains
the updated version of the VB 6 runtime that will automatically set RIM and
UE. We're running SP4 on our server so I'd assume this may mitigate the
problem? I'll use the VBCHKW2K.EXE tool to determine with dll's we may need
further take a look at. I take it that it's not necessary to recompile the
dll's have this problem resolved?
If we continue to have iis crashes, and considering we have the patches
installed, what would be our next steps?
I'd agree moving to a different reporting tool makes sense.
"David Wang [Msft]" wrote:
> It is a pre-requisite to have VB components have RIM and UE options to
have
> a chance to run reliably on a web server. Anything else is simply a
gamble.
> Running components that contain a UI which expects user input is also a
> no-no on a web server since it is not possible for a web user to ever
> interact with that UI -- so the server's worker thread literally hangs
> waiting for the UI. If you do this enough times, you exhaust the server's
> worker threads and the server hangs.
>
> I believe there are VB Runtime versions from Microsoft that automatically
> enable RIM and UE for a VB component if VB detects that it is run from
IIS.
> You will need this to work around your 3rd party reporting tool's
deficiency
> with RIM/UE.
>
> However, I highly recommend not using this reporting tool on the server --
> it simply is not programmed to do so and will likely cause more problems
> than it is worth. You should find a component that can actually do what
you
> want and is designed to run on a server.
>
> Client-side programming is VERY different from server-side programming, so
I
> would refrain from ever running client-side code on the server and
expecting
> optimal functionality. For example, client-side code tend to have UI, tend
> to be unstable and crash/hang (since the user can just restart it), tend
to
> only expect single-user interaction and not deal with concurrency, etc --
> all of those things are BAD NEWS for the server because it requires
> server-side components to NOT have a UI, be ultra stable and not
crash/hang,
> and expect multi-user concurrent access.
>
> --
> //David
> IIS
>
http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Ken" <Ken@discussions.microsoft.com> wrote in message
> news:15810DB9-BAC0-400F-95D4-A6E7339FD5E0@microsoft.com...
> There is a known problem with Active X dlls running on IIS 5 (retain in
> memory and unattended execution properties not checked) that may cause IIS
> to
> hang, crash (kb article 833891). Here's my question, we have a third party
> reporting tool (Datadynamics active reports) that contains a UI, hence
it's
> not possible to check the retain in memory and unattended exectution
> properties of the dll. What impact do these type of dll's have on IIS
(they
> are registered and do not run under COM+)?
>
>
>