Interface not registered

Arggghhh....

After typing in -safe-mode I assume you clicked the OK button to start DWT?

Why don't you try again but this time use this 64 bit version download http://www.dependencywalker.com/depends22_x64.zip
Yes, I did click the ok button. I repeated the instructions several times but I got the same results.

The x64 however was different. I get an error message that says "Errors were detected when processing "c:\program files (x86)\mozilla firefox\FIREFOX.EXE". See the log window for details." I click ok and click on profile but it will not allow me to select "Start profiling..."

Here are the errors in case you need to see them.

Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
 

Attachments

  • Untitled.jpg
    Untitled.jpg
    269.9 KB · Views: 3
Well.... I don't know why Dependency Walker x86 version won;t work for you. So, a new idea. Let's try resetting your download folder location and see what happens after a reset.

Click the orange FF button->Options->Options (or if you have the Menu bar, click Tools->Options). On the General tab, click Save Files to and Browse to a different folder location, click OK.

Now from the Orange FF button, click Downloads. Will it open to new location?

/* EDIT */
btw.. curious... Is this a problem that started happening recently or has it been around awhile or since you started using FF?
 
Well.... I don't know why Dependency Walker x86 version won;t work for you. So, a new idea. Let's try resetting your download folder location and see what happens after a reset.

Click the orange FF button->Options->Options (or if you have the Menu bar, click Tools->Options). On the General tab, click Save Files to and Browse to a different folder location, click OK.

Now from the Orange FF button, click Downloads. Will it open to new location?

/* EDIT */
btw.. curious... Is this a problem that started happening recently or has it been around awhile or since you started using FF?

To specify, it isn't when I click downloads that I have trouble. I click on downloads and it opens to a new tab with a list of all of my recent downloads. I right click my recent download and click open containing folder. When I click open containing folder I get the "Interface not registered" message. Here's a strange thing that I just found. I downloaded a picture and when I double clicked on it in the download list it would open up the pic without a problem.

I reset my download folder location but I still get the interface error.

Sadly, I'm not too sure when I started noticing this error. I think it was around the time I got a virus on this computer. Not sure if it was before or after I had gotten the virus. I came to this very website and the people that helped me did a good job showing me the steps and helped me get rid of it. I'm sure the virus is gone but I think it may have corrupted some things on my computer in my opinion.
 

Attachments

  • Untitled.jpg
    Untitled.jpg
    71 KB · Views: 3
  • Untitled2.jpg
    Untitled2.jpg
    70.8 KB · Views: 3
it isn't when I click downloads that I have trouble. I click on downloads and it opens to a new tab with a list of all of my recent downloads. I right click my recent download and click open containing folder. When I click open containing folder I get the "Interface not registered" message.
OHHHH! NOW you tell me :)

That's OK. I'm using this as a learning experience until either you and/I or throw up our hands and decide to call it quits!

That said, I've been doing my homework, some reading and uhhh, some more looking around. I've learned some new things and found another cool tool - that will hopefully work on your machine.

In quick overview: there are two types of public functions inside of a DLL (fyi: "public" functions are available for other software modules to call/invoke)
> Exported Functions
> COM Objects

So theory is that firefox may be invoking a public function that now doesn't exist - perhaps due to a corrupt dll that was corrupted by the virus. Given that theory I googled and found a tool from Nirsoft. (sidebar: I LOVE nirsoft freeware tools :) ) Firefox is a 32-bit app so I'm guessing we need the 32-version of the tool. Download DLL Exporter (32-bit. Unzip to a folder on your Desktop.

FF released a new version today. Update to v24.0. You might first see if problem went away? If not,
> Open FF in safe mode
> Double click the downloaded file dllexp.exe to run it
> Tool opens click What to Scan boxes to scan exported functions and COM libraries (see image below)
> Select Load functions from all DLLs attached to process then scroll to and select firefox.exe the click OK
> Watch lower left corner to see when it's done. Click Ctl-A to select all items, then Ctl->S to save
> Save As Type pulldown box appears under Filename box. Be sure you change it to Tab Delimited Text file!

You;ll have to Zip the text file so it;s small enough (< 1MB) to upload to TechSpot.
/* EDIT */
p.s. There's no need to quote everything when there's no ambiguity. And if you simply want to address different people in the same post,you can just start with, for example, the @ sign folllowed by the user's name
DLL Export.jpg
 
Ha, well at least we cleared up some of the confusion. I was able to use the 32 bit version of DLL exporter. Also, I'd like to thank you and everyone in this thread for taking the time to help me with this problem.

Anyway, here is the zip.
 

Attachments

  • Firefox.zip
    715 KB · Views: 11
My instructions should have said "Open FF in Safe Mode and re-create the error" before you run the DLL Exporter tool. I just want to make sure if you did it that way or not. If not, sorry for wrong instructions. Could you try again after re-creating the error?
 
Two things .... Stop FF auto update so we can both stay at the same FF v24.0 till we decide to both upgrade at the same time.

In FF Options, click the Advanced tab then under FF updates choose Never check for Updates

I also learned that shell32.dll contains many Windows Explorer functions, including many OpenFolder functions used by FF. Also from what I read, shell32.dll should've been checked when you ran SFC, but it seems such an important piece of the puzzle I'd like to double check for ourselves.
> Download and install HashTab
> Right click C:\windows\syswow64\SHELL32.dll, select Properties->Version. I assume the Version is from Microsoft? What is the version number?
> Next go to the Properties->File Hashes tab. Click on the MD5 checksum and paste into your TS post

/* EDIT */
p.s. On behalf of everyone, "You're Welcome". Everyone here is happy to try and help :)
 
p.s. On behalf of everyone, "You're Welcome". Everyone here is happy to try and help :)
LookinAround. Not too many people are going to be able to help the OP, if that's what you are hinting ;) :) Sorry, that includes me :D
All I can gather is the problem may be some combination of DCOM, corrupt major kernel file(s), and/or mixed 32-bit and 64-bit software failing to match. I last understood something of what was going on at post#51 with the two errors and two warnings making some sense, but failing to identify what they actually referred to......
I do hope you can continue to progress, but on the whole it does look to be a case of 'when malware has made a big enough mess, your least worse option is often a clean re-install'. There is always a thought from me - sr51463 I can never say too often 'there should have been a backup drive image to restore from'
 
gbhall The bottom line is still that everyone here on TechSpot are here because they're trying to help :) And I think sr51463 appreciates everyone's effort (if I may be so bold as to paraphrase for him or her)

As to the rest, yes, I agree with you that things could be quite the mess after the virus. But after some more reading about DLL's and stuff, I had this one more idea to try (I'll explain for anyone reading in the future --- and hopefully the approach will work for this case!
  1. DLL Exporter will list all the DLLs attached to a running process along with all the public functions within
  2. I get the output list from the problem machine after re-creating the problem. And compare it the output list from a machine where everything works
  3. To narrow the scope of those 40,000 or so lines of data in those lists, use Excel to compare the two data sets. a) Import both output lists into an Excel spreadsheet, b) sort each list by DLL name c) Then, for each row, define an EXCEL function to compare each line of the two datasets. The function will turn the line GREEN if the DLL and function names in a row match, otherwise RED . (And insert/offset additional cells to compensate for any differences to put remaining rows back in sync)
  4. My hope is these diffs this will narrow the scope of what to look at and if very, very lucky perhaps something will jump out as I skim through all the REDs
 
gbhall Yeah, I'm kicking myself for not having done that. At least I know better now.

LookinAround the version is microsoft and it is 6.1.7601.18222 And here is the MD5 checksum E02781D4871844DCD30DF1D69A650F78

Also, is it normal that my api-ms-win extension files appear as hidden? Here's a pic. Seemed strange to me.
 

Attachments

  • Untitled.jpg
    Untitled.jpg
    536.2 KB · Views: 4
Also, is it normal that my api-ms-win extension files appear as hidden? Here's a pic. Seemed strange to me.

Yes, it is normal. Those file properties are read, read-and-execute, hidden. In other words they are protected from change as much as a Windows file can be (which is not a lot). Remember you would not have seen those at all before changing your rights to see hidden and system files. There are many like that. To avoid further concern just turn off the visibility of system and hidden files.
 
3 TechSpot members with Win7 64bit generated DLL Export output data sets for me. In addition, I also have a Win7 32bit DLL Export from my own machine (since FF is a 32bit it should use most of the same 32bit DLLs)

I just discovered something interesting (I think). actxprxy.dl is part of everyone's DLL Export output (even my own Win7 32bit output) except it's not referenced in yours! Let's check it out.

I find it much easier to search for files using SearchMyFiles, then with Win7 search, so let's use it.

Download SearchMyFiles x64 from Nirsoft
> For Base Folders Browse to search your C: drive
> For Files Wildcard enter actxprxy.dll. Click Start Search

Only one copy of actxprxy.dll should found. The location on a 64 bit machine is C:\Windows\SysWOW64\actxprxy.dll. Rt click its properties and tell me the version number and the MD5 hash sum
 
It appears that I have 8 files with the same name. here is the MD5 hash sum for C:\Windows\SysWOW64\actxprxy.dll.

D2958325C1AE1AE37A83334C6229E3BC

And here is a pic of the 8 files.
 

Attachments

  • Untitled.jpg
    Untitled.jpg
    188.3 KB · Views: 4
Your C:\Windows\SysWOW64\actxprxy.dll is legit. Its MD5 matches the 32-bit version of that same dll on my machine (which is what I would expect as SysWOW64 is where windows keeps 32 bit versions of 32-bit standard dll's on a 64-bit machine)

As to those directories with winsxs in its name: Winsxs stands for "Windows Side-by-Side". Windows allows multiple versions of the same dll to exist on a machine. Reason: Different apps were built using different versions of the Visual C++ libraries. So these additional versions under winsxs are likely different versions needed for the different versions the Visual C++ libraries e.g C++ 2005, C++ 2008, etc.)

I'm not so sure of what's under C:\Windows\system32. In any case, let me first check with the TS members with 64 bit machines before the next step. (Which will be make sure the proper dll is registered)
 
Just a quick point, none of those versions on the OP machine has been accessed since mid-2011. I doubt if the problem has been present since then ! Still, the evidence will lead where it will.
 
gbhall Good (and interesting) catch! (y) Yes, that's a curiosity :confused: So will see what happens next once we get the right dll registered.

sr51463 After more thought, I'll guess the actxprxy.dll under windows/system32 is probably te 64-bit version. Will check. In any case, I should receive my own Win7 x64 PC tomorrow! so will wait till I have it hooked up to check, myself, before my next post. Also, my niece is pregnant and due towards end of next week. So, if I suddenly go into "radio silence" next it's because I'm travelling (probably will be gone several days to a week)
 
This continues to be a good learning experience... I hope it helps to fix your problem as well!

We're interested in C:\Windows\SysWOW64\actxprxy.dll and your copy is legit. But since it didn't appear in your DLL Export, I'm wondering if it's registered on your machine.

Download RegDllView 32-bit from Nirsoft. It displays registered dll/ocx/exe files. If needed, click the Name Only column header to alphabetically sort the files by name.
> Are you seeing actxprxy.dll listed?
> Does it show file path C:\Windows\SysWOW64\actxprxy.dll?

Here's a snapshot of what I see on a Win7 x64 machine where it's registered and FF is working

RegDllView.jpg
 
Well, I don't see actxprxy.dll listed anywhere. Here is a picture with all the a's that were listed.
 

Attachments

  • Untitled.jpg
    Untitled.jpg
    658.1 KB · Views: 3
Well, that fixed it. I'm happy to report that I no longer get the error message. In addition to that, my control panel which had been unresponsive when I clicked some of the features has been fixed as well.

I'd like to reiterate how thankful I am for everyone's help. I really appreciated everyone's efforts and I learned a great deal from this experience.
 
Yoo-Hoo! Bazinga! (y)

You're welcome. I learned a lot too through this process :)

One last quick question: Use SearchMyFiles again to look at [FONT=Consolas]C:\Windows\SysWOW64\actxprxy.dll [/FONT]again. Has its Last Access Time changed?

I have a guess. If true, it's a subtlety worth knowing: Although SFC replaces corrupt Windows files it does NOT fix unregistered files! That would be why gbhall noticed an old Last Access Time on C:\Windows\SysWOW64\actxprxy.dll

/* EDIT */
Correction. Use SearchMyFiles to check LastAccessTime again

/* EDIT2 */
Huh. When I run check on my own Win7 x64 LastAccessTime is still 2010 as well!!
 
Back