Asked by:

MHT/MHTML's Not Opening in IE9

Question

So I've had this issue for quite some time now, but up until now, just kind of dealt with it by saving the files to disk, then opening them in Firefox using an extension to provide support for these types of documents.

For a while now, attempting to open a MHT or MHTML document in Internet Explorer brings up a blank page, with a prompt to download the file. This occurs with both local, intranet, and remote files. I saved some example files, and I've taken some screenshots
to better illustrate the current issue.

Resetting my Internet Explorer using the button in the Advanced Settings tab.

Verifying that MHTML and MHT files were associated with Internet Explorer.

Unassociating and reassociating the MHTML and MHT file extensions with Internet Explorer

Completely removing the registry entries under Software\Classes\.mht & Software\Classes\.mhtml. (in addition to the keys that they pointed for to provide information for opening the file) Afterwards, I reassociated the extensions with Internet Explorer

Ran a FixIt or two that were centralized on fixing IE9 issues, but none of them turned up any errors.

I attempted to uninstall, then reinstall Internet Explorer 9, but an issue occurred which left me in a state where I didn't have Internet Explorer 9, and at the same time received an error when attempting to install it. To avoid the hassle of diagnosing
the issue, I just did a System Restore.

As you can see in the screenshot below, Windows indicates that Internet Explorer is the default handler for these file extensions.

Finally, I've gone ahead and exported the registry entries associated with the two file extensions, as well as CLSID's pointed to by the entries. (I removed some of the entries for empty subkeys leading up to the children keys to save some space)

Lastly, one of the discussions I've found while trying to diagnose this problem over the last few months mentioned a URL that consisted of mht:\\path. It occurs to me that that would indicate a registry entry to a URL Protcol for the mht protocol. I couldn't
seem to find a registry entry for that on my computer, however.

All replies

'Fraid that didn't do it. To be honest, though, I've pretty much conceded to this not working correctly until I get around to reinstalling Windows. (Which I intend to do at some point in the next year, anyways, since I just realized that I could be running
x64, even though the computer camed shipped with 32bit) Whatever I did to create this problem stems from about a year and half of small (and sometimes large) tweaks to get the shell to behave the way I want it, so I kind of doubt the problem is reproducable.
If someone feels like posting the registry entries associated with handling this type of document(I've checked all the binaries that I know about associated with it, and I'm pretty sure none of them are the cause), I could go through each entry and see
if I notice anything off. Otherwise, it's something I can just accept for the time-being.

Also, interestingly enough, the Windows Mail Active X handler for MHTML/MHT files is working fine. This issue seems to be limited to the Internet Explorer's handler, which is a shame since that means that any applications embedding IE's
Activex Document Server are affected if they try to utilize mhtml files.

It happens with any MHT or MHTML I attempt to open, regardless of what browser it's been saved from or how it was created. For instance, when I attempt to run
Microsoft's All In One Code Framework, after the intial load, Internet Explorer will pop up prompting me to download the MHTML/MHT file that the application should've been displaying. I expect that's as a result of them
using an embedded Internet Explorer component to display it.

I'm afraid turning off Protected Only mode hasn't fixed the symptom, either. (Even tried turning it off for all zones, and still had no luck)

I ran it through Procmon, but unfortunately I've got some projects for work I need to finish that will have to take up my time for now. When my schedule clears up a bit, I'll take some time to scutinize the logs. A quick glance over shows that IE appears
to be having trouble locating a ContentType for the MHT document. After a while, it settles on application/octet-stream. Anyone know if that's the mime type it's supposed to be using?

when I attempt to run Microsoft's All In One Code Framework, after the intial load, Internet Explorer will pop up prompting me to download the MHTML/MHT file that the application should've been displaying. I expect
that's as a result of them using an embedded Internet Explorer component to display it.

A quick glance over shows that IE appears to be having trouble locating a ContentType for the MHT document. After a while, it settles on application/octet-stream.

FWIW I opened that in IE10 on W8 CP from both IE and WE. It was quite slow loading but there was no prompt.

I imagine that if you are getting that Content-type that could explain your symptom (e.g. possible binary, so security implications.) I will try and redo this on IE9 on W7 with ProcMon to see what I get--also see whether it is so slow rendering
then and whether I can open it directly from WE without having an iexplore.exe already open. I do get a symptom like you are reporting for .URL files in IE10 when there isn't an iexplore.exe already open, so I probably should try to
understand that case too. Not now though, because I need it open to compose this reply. And maybe not later because I will probably have it open in order to see this as a reminder. ; )

I will try and redo this on IE9 on W7 with ProcMon to see what I get--also see whether it is so slow rendering then and whether I can open it directly from WE without having an iexplore.exe already open.

This has been enough of a reminder. FWIW I found the .mht.lnk in Recent Items on my other partition and opened it without problem while IE was not active on W7. It opened quite quickly--compared with the
slow rendering on IE10.

Oops. I just realized that out of force of habit I launched that from Administrator: Command Prompt. I think that might have a similar effect to using Protected Mode off. The reason I did that is because WS
still hasn't found what I easily found in Recent Items. So now that I have the path I can end its misery...

In fact, even when I open that directory explicitly WE won't even let me see those .lnk files so I can't do that test. I can drill down to where the .mht is and try to open it using AutoComplete in a normal mode IE9 window but it shows Cannot
Display... which the troubleshooter interprets to mean that the File:// protocol syntax is causing a problem. I suspect what it really should be saying is that security/obscurity is interfering and it won't say why.

Again, I can explicitly launch an IE window Run as Administrator and avoid any problems opening it.

QED. And I don't think that there is any point now in trying to run ProcMon to try to untangle this from all the obfuscation inherent in security/obscurity.

Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.