Re: App.Path in Class_Initialize (or VB Runtime threading bug?)

From: DJThompson (DJThompson_at_discussions.microsoft.com)
Date: 01/05/05

  • Next message: Tony Proctor: "Re: App.Path in Class_Initialize (or VB Runtime threading bug?)" 
    Date: Wed, 5 Jan 2005 01:09:03 -0800

    Thanks Tony.

    Unfortunately we have already double-checked the "retained in memory" and
    "unattended execution" settings.

    The "recent changes by Microsoft" I referred to are those described by MSDN
    article 307211 at
    http://support.microsoft.com/default.aspx?scid=kb;en-us;307211 which are
    suspiciously close to the above two settings.

    However, as the internet remains fairly quiet on this front, it must be a
    problem with our configuration and not with the VB runtime - maybe something
    we've set in Component Services when installing the component.

    If we track this down I'll post our findings here.

    Thanks again,
    David.

    "Tony Proctor" wrote:

    > The VB6 runtime is only safe in STA threads (i.e. what you call "apartment
    > threading"). Both COM+ and IIS (which is itself a COM+ environment) offer
    > this type of threading, and so VB6 should be OK.
    >
    > I know of no problems with Replace() or Dir(), or of any MS changes that has
    > broken them. We use these environment extensively without encountering
    > similar problems.
    >
    > One thing that's always work checking is that all your VB6 DLL have both
    > 'Unattended execution' and 'Retain in memory' set in their project
    > properties. This is mandatory for it to be properly thread-safe in these
    > environments.
    >
    > Tony Proctor
    >
    >
    > "DJThompson" <DJThompson@discussions.microsoft.com> wrote in message
    > news:43AE87DF-4341-496F-8D9D-D93567A6C700@microsoft.com...
    > > We're having the same symptoms. For us, it appears to be a threading
    > problem
    > > with VB runtime. We have an ASP application calling a method in a
    > component
    > > registered in COM+ Services. Our code works fine (famous last words) but
    > > when we call Replace() or Dir() in the VB Runtime (MSVBVM60.DLL) we get
    > > "ActiveX component cannot create object". Our ASP pages work fine until
    > the
    > > site is under heavy load. We presume that as IIS starts using more and
    > more
    > > threads for serving requests, we end up calling the Replace() and Dir()
    > > functions from multiple threads simultaneously. When this happens, some
    > ASP
    > > page requests will fail with the aforementioned error.
    > >
    > > We originally noticed the behaviour when continously pressing F5 very
    > > quickly - some requests would fail.
    > >
    > > **We can reliably reproduce the error in the VB runtime** simply with a
    > > small multi-threaded C# application (source available: post here to
    > request)
    > > which calls a method in a VB6 COM+ DLL multiple times simulaneously across
    > > multiple threads. The VB6 DLL method just calls the Replace() function.
    > As
    > > a result, we get "ActiveX component cannot create object" errors arising
    > from
    > > making the Replace() call. This error is not arising as a result of
    > > evaluating the parameters to the call.
    > >
    > > Our VB6 DLL is configured to use apartment threading - it appears that the
    > > Replace() and Dir() functions no longer work in this model as the result
    > of a
    > > recent change by Microsoft.
    > >
    > > Does anyone know of a work-around until Microsoft notices & patches?
    > >
    > > Thanks!
    > >
    > >
    > > "Jason R. Schmidt" wrote:
    > >
    > > > Hi, I am having a strange issue with a class in VB6. I am running a
    > > > webserver using IIS on windows 2000 and an ASP UI. I am receiving
    > random
    > > > "activex can't create component" errors. If you refresh the page, the
    > error
    > > > goes away. If you refresh again, it will happen. This occurs randomly.
    > If
    > > > IIS is restarted, the web page doesn't encounter this error until around
    > a
    > > > week later.
    > > >
    > > > The class causing the problem built some logging path information in the
    > > > Class_Initialize method by using the App.Path object. I determined this
    > > > object was causing the problem because the error hasn't happened since
    > we
    > > > removed it.
    > > >
    > > > Just wondering if anyone had ever seen this?
    > > >
    > > > Thanks
    > > >
    >
    >
    >

  • Next message: Tony Proctor: "Re: App.Path in Class_Initialize (or VB Runtime threading bug?)"
    Loading