Re: About protected memory in COM(in-process)

Tony Johansson <johansson.andersson@telia.com> wrote:


My guess is, the DLL makes assumptions about lifetimes of its various
objects, which no longer hold. The main difference between VB6 and .NET
(when it comes to interfacing with COM) is that the former is
reference-counted while the latter is garbage-collected. When a VB
variable holding a COM interface goes out of scope, VB immediately calls
Release on the interface pointer. When a C# variable goes out of scope,
the object it refers to (a .NET wrapper around the interface pointer)
becomes orphaned and eligible for GC. Some time later, noone knows when,
the garbage collector will get around to finalizing this object, at
which point Release will be called.

So objects stick around longer. If the DLL, say, makes an assumption
that only one object of a certain type would be alive at a time, it's in
trouble.

Another possible reason: ASP.NET application runs inside IIS process
under a pretty locked-down account with limited privileges. Could it be
that the DLL is trying to do something it doesn't have rights to, and
gets security-related errors? E.g. an ASP.NET application cannot, by
default, read or write arbitrary files on disk.

Why don't you debug the DLL and figure out where it fails?
--
With best wishes,
    Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925