IE 9 update crashes chms when linking to a nonHTML file

[tems]

It is my understanding that back in the summer the IE9 update caused a crash when the chm attempts to link to a non-html file (such as a pdf or a doc). I've seen this reported in numerous places and I have since discovered that our CHMs crash when the user clicks on one of our links to a pdf buried inside the chm. This is on 64 bit machines running Windows 7 and IE9. Even worse, the crash is taking our application down with it, which I hadn't realized was possible.

Does anyone know of a fix for this?

[i-tietz]

Wait for bugfixes for IE9 (are there any already?) before wasting resources for finding workarounds. But you can always start by adding the browsers and their versions to your document for system and hardware requirements for your software, because the help is part of the software ...
Or do you have customers complaining about the software not running under Windows 7, while the system and hardware document states that it runs under Windows XP only?

[tems]

Telling users they can't can't run our application under Windows 7 because of a Help issue would be unacceptable not only to our users but to the rest of my company. Our software is fully compatible with Windows 7 except for this issue. Luckily, we only have 4 pdfs we're linking to, so I've converted those to html files for the time being.

I'm more concerned, in the long run, about these new limitations to compiled Help, and if they will continue. I'm not even sure Microsoft considers this a bug.

[i-tietz]

Telling users they can't can't run our application under Windows 7 because of a Help issue would be unacceptable not only to our users but to the rest of my company. Our software is fully compatible with Windows 7 except for this issue.

I didn't mean Windows 7, just IE 9 ...
The help is part of the software. There are limits to under which circumstances the software runs and there are limits to under which circumstances the help runs, too. If they change those settings on their own account and the software doesn't run anymore, your company will deny liability - and rightly so! If they change other things and the help doesn't run anymore, it's the same situation.
That is something users have to know - so it's you who are supposed to tell them! If you haven't done it yet, you will indeed have problems. But you should at least correct that mistake and start now by telling them.

[RamonS]

I'm more concerned, in the long run, about these new limitations to compiled Help, and if they will continue. I'm not even sure Microsoft considers this a bug.

Doing anything for help (CHM) is not on Microsoft's radar. I don't know when the last change was made to the help viewer, but it is ages ago. The problem with CHM is that it is tied at the hip with IE. Any change in IE can make a difference to CHM. Also, any IE settings will affect CHM.
Microsoft should put some effort into crafting a new help format, but they are way to busy with destroying working UIs with ribbons and tiles, so forget about that.

[tems]

I agree with you, generally speaking. I also know that when you have a large user base there will be a number of users who just automatically update to the latest browser. When their application crashes as a result they will be putting additional load on our customer service line.

Part of my job is to try to prevent that--so if it's just a matter of converting a few pdfs to html that's what I'm going to do (I would address it differently if our system linked to large numbers of pdf and doc files). I've already sent out a bulletin to users who have installed the previous release which included the pdfs.

The point of my question was to find out if anyone had heard if this issue was going to be fixed. I've seen nothing officially from Microsoft. And it affects our ongoing Help development efforts.

[LTinker68]

I've seen this reported in numerous places and I have since discovered that our CHMs crash when the user clicks on one of our links to a pdf buried inside the chm.

Just out of curiosity, is there any particular reason why you have to deliver your help as a CHM instead of WebHelp or even DotNetHelp? As RamonS mentioned, Microsoft does nothing to improve or fix the CHM viewer; they merely support the use of it to display help. At some point, I can see them dropping even that. It might be a good time to switch to WebHelp. That said, if your help will be running locally on their computers, they'll still have problems opening PDFs from the help, as you'd have to enable the MOTW feature so users won't get that yellow warning bar in IE, and enabling MOTW will disable the ability to launch PDFs from the help.

[tems]

I've been recommending for several years that we switch to webhelp for all of the reasons mentioned. There's been resistance because of the number of files and the need to rewrite the context sensitive links, and other issues beyond my control. Perhaps this will be the issue that swings opinion around.

[i-tietz]

There's been resistance because of the number of files and the need to rewrite the context sensitive links

1. Usually, if you have a big software, you have many help files. But if the software is big, the number of help files doesn't matter - those times are over. If you have a small software, you have fewer help files. Whatever way I look at it - in comparison to the software, the size of the help or the number of help files doesn't matter ...
2. You don't work with the Flare Alias Files and header files from your development containing the control IDs? You give the developers the path to each topic you want to be called? Goodness. Then yes, your developers went the wrong way. They are generating a lot of cost ... unnecessarily ...

3. Having a single file for each topic also means it's easy to update. You could only update those files that need an update and leave the rest. That even reduces the volume of a software update ...