Classic ASP apps generating error '80070002'


  • Hello,

    I have a .Net 2.0 dll that is registered for COM interop.  This dll provides authentication for multiple web applications, so we have it registered in our webserver's GAC.  We've also registered it using "regasm my.dll"  For a while it was working with all of our applications, both classic ASP and .Net 2.0 varities.

    Recently, our classic ASP applications started giving "error '80070002'" on the line where they tried to instantiate the object.  The weird part is that our .Net 2.0 applications are using the dll without any problems.  None of our applications have a local copy of the file; they all rely on the GAC version.  I've checked in the webserver's c:\windows\assembly directory and the correct versions of our dll are in there.

    It is my understanding that being in the GAC would allow all applications access to it.  I haven't been able to find any reason why one set of applications can use it but not the other.

    Any help is appreciated.

    Monday, January 14, 2008 3:02 PM

All replies

  • So far to troubleshoot the problem can you help to perform the steps below?
    1. Use the OleView tool to show the tlb definition for the assembly you are generating. If we check the register for Com Interop, there will be a tlb file generated by IDE which is located in the same directorty of the
    generated .NET assembly.
    the tool is located in the path below.
    C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\oleview COMTest.tlb
    And copy/paste all the information

    2.Commonly in the simple test sample, it should use the .NET buildin
    assembly without any customize DLL. However we still can use the Assembly Binding Log Viewer tool to see if there is any binding error.

    3. You may try to use the Filemon and Regmon to see if there is any access denied or not found error.

    You can check out this discussion for a very similar issue Creating a COM interop using VS.NET 2005?.
    Wednesday, January 16, 2008 4:36 AM
  • Our web servers don't have the Visual Studio tools installed; is there a way of getting this information without installing extra software?

    What we've done in the past (this has happened twice in the past six months) is re-install the DLL, but we'd rather not see the problem at all.  We've done this in two steps:
    1) Run "regasm my.dll" without any switches (it has a .snk file)  Should we be using the /tlb switch?
    2) Drag and drop the dll into the windows\assembly directory.

    Do these steps not permanently install our DLL?  I'm wondering if a server reboot would cause it become unloaded.

    Thanks for your help,
    Wednesday, January 16, 2008 4:29 PM
  • I realized I could run OleView remotely, but then also discovered we don't have the .tlb on the web server; could that be the problem?  Or does running regasm create a tlb automatically?

    Thursday, January 17, 2008 3:10 PM
  • I suggest that you can register the assembly using regasm.exe and /tlb switch, and test to see if the problem still exists.

    Like this:
    Code Block

    regasm myTest.dll /tlb:myTest.tlb

    Friday, January 18, 2008 7:07 AM
  • Thank you for your continued help; unfortunately, by the time you suggested the /tlb switch the DLL was working again :- /  Yesterday, though, it stopped again.

    Running regmon I found that it was sometimes looking in HKCU and not finding the key, but finding it in HKCR:

    18.14881134       w3wp.exe:1008                OpenKey             HKCU\Software\Classes\CLSID\{C59FE32D-B543-37FD-9EDD-8900523699A0}  NOT FOUND                      

    18.14883804       w3wp.exe:1008                OpenKey             HKCR\CLSID\{C59FE32D-B543-37FD-9EDD-8900523699A0}                SUCCESS                             

    18.14885712       w3wp.exe:1008                QueryKey            HKCR\CLSID\{C59FE32D-B543-37FD-9EDD-8900523699A0}                SUCCESS              Name: \REGISTRY\MACHINE\SOFTWARE\Classes\CLSID\{C59FE32D-B543-37FD-9EDD-8900523699A0} 

    18.14889145       w3wp.exe:1008                OpenKey             HKCU\Software\Classes\CLSID\{C59FE32D-B543-37FD-9EDD-8900523699A0}\TreatAs                NOT FOUND                      

    18.14890862       w3wp.exe:1008                OpenKey             HKCR\CLSID\{C59FE32D-B543-37FD-9EDD-8900523699A0}\TreatAs                NOT FOUND

    There were more entries of that nature - when it was HKCU\Software\Classes\CLSID\{clsid} it would fail, but HKCR\CLSID\{clsid} worked.

    Then I found this post -
    This person had a similar problem and found the keys should be pointing to HKLM (and it seems like the proper keys exist in HKLM).  If this is the case, do you have any idea how or why it's looking in the wrong place? 


    Tuesday, January 29, 2008 3:05 PM
  • Since I now know this is registry/regasm related, is there a better forum to post this problem?

    All ideas are appreciated.

    Monday, February 18, 2008 8:02 PM
  • Mike,

    Was curious as to whether you ever found an answer to this problem.  I am getting it too now and MS Support seems a little stumped.

    This is brian
    Thursday, November 18, 2010 7:02 PM