Win7 Desktop URL shortcuts open blank page in IE10

UsernameIssues · 22 Aug 2015

Thanks for the reg file. As you noted, it looks good. I compared it to a Virtual Machine with a fresh install of W7pro64bit with IE11 and updates. Even though you are using IE10, there should be no difference for that key.

Do you know what might be preventing IE from changing the key that you removed?

You can run either or both of the hot fixes mentioned if you want... but I would sure feel better about the hot fixes if the webpage offering them said that they applied to IE10. Having a MS person say that they apply to IE11 is of some value, but if that is true, then MS should update those two web pages.

I've seen the hot fix mentioned under method 1 in that post applied to IE11 in threads in this forum. No harm seemed to come from it. I'm not sure if it fixed anything that a complete IE reset would not have fixed. You might try a reset first - including step 5. If that does not fix the issue, it is up to you if you want to try the hot fixes

rwhite1 · 22 Aug 2015

I don't know. If you mean the "UserChoice" key, IE puts it back if I tell it to make itself the default browser so it's not prevented from doing that.

I've done every reset I can. Let's try the hotfix.

*******************************
Tried the Hotfix:

It wouldn't install. It said it was not applicable to my computer. MS support strikes again. Sometimes I think they should rename the "Start menu" world icon in the taskbar to "The Death Star".

It looks like more reseach is required. It may be best to fix the File Association dialog problem first. We'll see.

**************************
UPDATE:

The file association dialog problem has been fixed. MS Access 97 left behind an icon handler file that has been a problem for the windows shell ever since it came out - soa800.dll. I used ShellExView to disable it and all was well again. From my past recollection, if the file is needed, the problem can be managed by choosing where in an app install sequence Access 97 is installed. BUT, Access 97 is recognized as not WIN7 compatible. One could try using it in WINXP compat mode, but I have no idea how that would turn out.

Back to the shortcut problem. Isn't this fun? Actually, it is. UNI... don't give up hope.

rwhite1 · 24 Aug 2015

SevenForums suggests that the final answer to the problems discussed here be posted, so here goes.

1. No answer was found to the IE desktop shortcuts opening blank pages; however, UNI's workaround in his post 9 above works and was found to be a good substitute. I implemented it by removing the "UserChoice" registry subkey shown in his post. Note, though: the problem will return if another browser is set as the default and then later replaced by IE. I also found six missing registry entries which I corrected, but it didn't help.

2. The broken "Associate file type with protocol or program" process was fixed by disabling the offending "soa800.dll" file from Access 97 as described in my post 12 above. Doing this, however, broke Access 97.

Access 97 hasn't been one of the best programs to survive OS upgrades. One may recall that Registry entries blocked MSA97's installation and needed manual intervention to install it after WINXP-Sp2 broke .OCX registration. Documentation for that is elsewhere.

Many thanks to UNI for his help. I respect his wealth of knowledge.

UsernameIssues · 24 Aug 2015

You could run Process Monitor on the working computer and compare the events with the flawed one. There is nothing to install, just unzip it and run it.

Double click on a URL shortcut file on the desktop.

Let IE go to a blank page.

Stop the data collection by Process Monitor.

Use Ctrl-F to find the first entry for the shortcut's name. It will probably be Explorer passing the shortcut to the OS. You can use filters to only include Explorer and IE. Let me know if you need help using Process Monitor. There are lots of YouTube videos showing its use. Here are two of mine.

There will be lots of entries. Hopefully, the difference between the two computers will jump out at you.

rwhite1 · 25 Aug 2015

SOLVED!

I used PROCMON as you suggested and something did pop (or is it poop?) out at me. PROCMON's output from the successful system contained the shortcut's name. The output from the problem system did not...anywhere. Not in the output from the configuration that worked (with IE NOT as the default browser) nor the output from the configuration that did not work (with IE set as the default browser).

To shorten a huge amount of detailed data sifting (as you know 10's of thousands of data entries), I found two CSLID references early in the bad listing that weren't in the good one: B722BCC4... (for DOCOBJ.DLL) and C9025F3... Okay I'll stop.

Googling found they were more left over crap from Office 97. I uninstalled Office 97 and everything is working fine. I know it's common knowledge that Office 97 was not fully compatible with WIN7, but I don't remember anyone saying it would break some of it too.

Well hopefully that's over. This had to be one of the more complex ones to solve. Good job. Thanks again.

On a related matter:
As I'm sure you know, PROCMON has problems on some 64 bit systems. One of mine for one. They say the fix is to copy and run the 64 bit extension PROCMON creates and puts in a temp directory. But, how do you do that when the extension is created and is then just as quickly deleted when PROCMON fails and closes? Nirsoft's Resource_Extractor has been recommended to extract it directly from PROCMON, but I don't see that RE extracts an executable binary resource. Any ideas?

UsernameIssues · 25 Aug 2015

Glad that you got it fixed. Good detective work.

I have not run across any problems with Process Monitor on 64bit system.
Perhaps because I only use the 64bit version on 64bit systems.

Each time that there is a new version of Process Monitor released...
...I extract the files to the folder where I keep it
...run the 32bit version
...stop the data collection
(leave the 32bit version running)
...copy the 64bit version from the temp folder to the folder with the 32bit version.

Process Monitor has an option to replace Task Manager. It has been a while since I tested that, but that swap failed if the process is started while running the 64bit version.

rwhite1 · 25 Aug 2015

PROGMON doesn't work on my 64 bit system. Here's what I'm reacting to:

Process monitor 3.1 will not work in Windows 7 X 6 - Sysinternals Forums

Apparently the 32 and 64 bits of the new 3.1 and 3.2 versions of PROCMON are now contained in the same program. When PROCMON detects a 64 bit system, it extracts a 64 bit version to the user's temp directory and runs the 64 bit version from there. But some 64 bit systems won't do it - mine being one.

On those systems, they recommend you get the 64 bit system from the temp directory and just run it directly. Only problem is PROCMON opens, creates the 64 bit file, fails, deletes the file, and then closes all faster than you can blink. Therefore the 64 bit program isn't available long enough to get it.

Take care.

UPDATE: Redwood file extractor got it out. The embeded resource is 1308. The binary will extract as binary.bin. It will run if the file extension is changed to ".exe"

UsernameIssues · 26 Aug 2015

Thanks for the link. I cannot imagine what would cause the 64bit version not to extract/run correctly.

At least you got the file extracted