Re: Error in loading DLL (Error 48)

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thanks for the response Tony.

It is our own DLL, we are not performing any Windows API functions or
anything like that and we do have the "Retain in Memory" , "unattended
Execution" and "Upgrade ActiveX controls" checkboxes set.

This DLL appears to be (at least on the surface) setup the same exact way as
other components that work in COM+.

These components all work fine when call through our web site. It's when we
try to execute (instantiate) this one DLL from a VB 6 executable which is
physically on the webserver. Note: all the other DLL's we instantiate from
this same VB 6 app work correctly in COM+.



"Tony Proctor" wrote:

> Sounds like it could be a threading problem gradley .COM+ is a
> multi-threaded environment. Running it outside of COM+ will use a
> single-threaded environment.
>
> Is the DLL your own, i.e. do you have the source code?
> Does it use any Win32 APIs (i.e. have any Declare Function statements)?
> Does it have 'Retain in Memory' set in the project properties?
>
> Tony Proctor
>
> "gradley" <gradley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:EFA24EC8-D35B-43AD-AEDB-F0A9C33133E8@xxxxxxxxxxxxxxxx
> > Hi,
> >
> > We have been running VB 6 DLL's in COM+ on Windows 2000 for a couple of
> > years now but have recently run into a problem with a single DLL.
> >
> > When instantiated from a website using Windows 2000 IIS 5.0, the component
> > works perfectly in COM+. We have an executable vb6 program that we run on
> > this webserver to simulate calling the COM+ components multiple times to
> test
> > performance.
> >
> > For some reason, 1 component does not load from this executabe while in
> COM+
> > "Error in loading DLL (error 48)." We have checked MSDN knowledge base
> but
> > the areas they recommend to look at did not help. If we take the component
> > out of COM+, it works. The other 4 components we call from this same
> > executable work fine in COM+.
> >
> > Any suggestions would be greatly appreciated.
> >
>
>
>
.

Relevant Pages

  • Re: [Full-disclosure] Cybsec Advisory 2011 0901 Windows Script Host DLL Hijacking
    ... file could lead to remote code execution? ... Windows Script Host DLL Hijacking ... Remote Command Execution Vulnerability ... Reference to Vulnerability Disclosure Policy ...
    (Full-Disclosure)
  • Re: LabView-Dll and c++ (with FieldPoint)
    ... i've just startet to work with LabView and am trying to solve a (actually ... functionality should be used as a dll in a c++-program. ... without FieldPoint-assistance which worked fine (i.e. to add up ... At this point i can continue the execution by pressing the ...
    (comp.lang.labview)
  • Re: [Full-disclosure] Windows Vista/7 lpksetup dll hijack
    ... However, from my experience under Windows 7 Ultimate in VirtualBox, ... payload will still run as the lpksetup halts for execution somewhere after ... loadlibrary is pointing to a dll on a remote system (our ...
    (Full-Disclosure)
  • Re: Debugging Apllication
    ... Exception handling is much slower when the debugger is attached, so if a lot of exceptions are being thrown, execution can slow down a lot under the debugger. ... Generally speaking, it's telling you that something executed some code that shouldn't be executed while a DLL is loading, even though a DLL was in fact loading. ...
    (microsoft.public.dotnet.languages.csharp)