« Previous Next »

Thread: Windows Server 2008 with Classic ASP and VB6 DLLs

Last post 01-06-2009 11:07 AM by CrispinH. 3 replies.

Average Rating Rate It (5)

RSS

Page 1 of 1 (4 items)

Sort Posts:

  • 01-05-2009, 4:00 PM

    • CrispinH
    • Top 500 Contributor
    • Joined on 09-17-2008, 11:10 AM
    • Posts 23

    Windows Server 2008 with Classic ASP and VB6 DLLs

    I'm migrating a Classic ASP website from a Windows 2003 box with SQL Server 2005 (where it worked quite happily) to a 64-bit Windows Server 2008 platform.  The website employs a VB6 DLLs that handle the SQL Server 2005 data access and SQL Server 2000 before that.  My new Windows Server 2008 platform uses SQL Server 2008 Express.

     I'm getting the following error message:

    Server object error 'ASP 0177 : 800401f3'
    Server.CreateObject Failed 

    I have done the obvious things like run regsvr32.exe on the DLLs and given NETWORK SERVICE full permissions (aside: should this be more restrictive?) to the containing folder.

    After that, and browsing round this forum, I ran Sysinternals Process Monitor to see if I could find any issues.  Process Monitor produces a formidable amount of information and I'm not yet that adept at filtering it.

    One curiosity was that the process w3wp.exe did a CreateFile operation with a path that appended web.config onto the page that was being browsed, so it looked a bit like:

    D:\<path>\mypage.asp\web.config

    and so the result was PATH NOT FOUND.

    The next anomaly was a QueryAllInformationFile operation with the path as the file path of my page.  This produced a BUFFER OVERFLOW result. 

    However, further on down the listing, I saw the ProgID of my DLL in a RegOpenKey operation with the path:

    HKCR\Wow6432Node\<ProgID>

    and the result was NAME NOT FOUND with a detail of Desired Access:Read.  Further attempts appear to be made to open this key with different Details being reported.  This item appears to be the problem and the previous two may or may not have something to do with it.

    Anyone any ideas as to how to solve what looks like a permissions issue?

    Regards

    Crispin

  • 01-06-2009, 12:38 AM In reply to

    Re: Windows Server 2008 with Classic ASP and VB6 DLLs

    CrispinH:
    to a 64-bit Windows Server 2008 platform

    Is the VB6 Dlls, 32-bit? If yes, you will need to run w3wp.exe in 32-bit mode.

    In IIS Manager - Application pools> Advanced Properties> Set Enable 32-bit Applications to True and recycle App pool.

    If above does not help, then it might be still permissions issue. Keep checking with Procmon.

    HTH.

    ~ Ganesh

  • 01-06-2009, 4:01 AM In reply to

    • CrispinH
    • Top 500 Contributor
    • Joined on 09-17-2008, 11:10 AM
    • Posts 23

    Re: Windows Server 2008 with Classic ASP and VB6 DLLs

    Hi Ganesh

    Thanks for the response. I took a look at that setting and it's already set to True

    Regards

    Crispin

  • 01-06-2009, 11:07 AM In reply to

    • CrispinH
    • Top 500 Contributor
    • Joined on 09-17-2008, 11:10 AM
    • Posts 23

    Re: Windows Server 2008 with Classic ASP and VB6 DLLs

    I've sorted it out with the help of Process Monitor which had an entry:

    HKCR\Wow6432Node\<ProgID>

    with the result NOT FOUND.  So I fired up Regedit and searched through the HKCR\Wow6432Node folder looking for the particular ProgID and other ProgIDs that I had registered.  Every ProgID but the one I was actually using was present. 

    I went back to the batch file that I used for registration (where it is the first in the list) to verify it was there, and it was.  So I opened up the Run box, tapped in C:\Windows\System32\regsvr32.exe and then dragged the DLL filename from Windows Explorer into the box and then ran it.  That did it.  It's still a mystery as to why the first item in the batch file actually failed when the dialogue showed success.

    The lesson is that if you think you've registered your VB6 DLL but it doesn't appear to be working, check it in HKCR\Wow6432Node to see if it's present.  Then of course make sure that the correct access permissions have been assigned to the DLLs (NETWORK SERVICE and IIS_IUSRS as appropriate).

    Crispin

Page 1 of 1 (4 items)
Microsoft Communities