Can no longer open CHM files across the local network after installing CU for Windows 1709 for x64 Systems (KB4103727)


  • We had previously used a group policy preference to set the following registry value, which allows the opening of CHM or Windows Help files from network paths.  We also place the network paths in the Local Intranet zone in IE, although it should automatically detect it as local anyway.

    SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions\MaxAllowedZone (DWORD) = 1

    This works perfectly for all of our users, until we install KB4103727.  After this we get a, "Can't reach this page error" from our CHM files.

    I double checked the registry and the Local Intranet zone in IE and everything looks like it should.

    Friday, May 11, 2018 3:36 PM

All replies

  • Hi Allen,

    How are you launching the chm files from IE... ? or are you using a burlesque WBC in a  exe/dll?

    exactly how do you place a network path in IE's security zone lists? eg. //servername/ resolves to the c://webroot folder on a server machine named servername running IIS.

    A host is not a network path.. try removing the server name from your IE Intranet sites list.

    Can you use the File>Open menu in IE? to launch the chm files (MS Compiled Html help executable) from either its network location or the machine %system% folder?

    ... you should be prompted to open or save the file, not launch it in IE.

    Is your company using Enterprise Site Mode Lists or FEATURE_CONTOL_BROWSER_EMULATION (for WBC applications)?

    all in all it sounds like you are using a WBC application. not IE.

    Is this application developed/maintained by another software company? Have you tried their support forums?

    Security updates to Microsoft Edge, Internet Explorer, Microsoft scripting engine, Windows app platform and frameworks, Device Guard, Windows kernel, Microsoft Graphics Component, Windows storage and filesystems, Windows Hyper-V, Windows virtualization and kernel, HTML help, and Windows Server.

    Doesn't tell us much to help you.


    Questions regarding Internet Explorer 8, 9 and 10 and Internet Explorer 11 for the IT Pro Audience. Topics covered are: Installation, Deployment, Configuration, Security, Group Policy, Management questions.


    Saturday, May 12, 2018 1:44 AM
  • Hi Rob,

    I'm not really launching it from IE, it is more that the CHM file is a compiled HTML help file that runs IE in an IFrame.  The process that is running when I launch it is hh.exe.

    The .CHM file is located on a network share on a file server.  We use a DFS namespace for this fileshare and using group policy, we map a network drive to everyone's desktop.

           File Share - \\ServerName\ShareName

           DFS Namespace \\DFSNamespacePath\DFSFolder

           Mapped Drive - T:\FolderName\file.chm

    We can add the share to the Local Intranet zone by using the file://DFSNamespacePath syntax.  In fact if I attempt to add T: to the Local Intranet zone, it can resolve it to file://DFSNamespacePath.

    I tried launching the CHM directly from IE, but it does not work if i choose Open.  I'm sure that it would work if I saved it locally because the CHM's still work fine when run from the local machine.  Unfortunately we have some legacy files that a lot of users need to access, and having to copy the CHM files to their local machine every time is a giant pain in the rear.

    We are not using Enterprise Site Mode Lists or FEATURE_CONTROL_BROWSER_EMULATION (for this atleast).

    These are very old help files and I don't know if the company exists anymore or could help us.

    Good catch on the "HTML help" for the Windows 10 update.  I wonder if the problem that I am having is an unintended side effect of their update, or if it was done to close a security hole.

    Thanks for your help!

    Monday, May 14, 2018 3:43 PM
  • We are having this same issue since updates this weekend. Some of our folks are pointing at KB4103712, which also lists security updates to HTML help.

    Like the OP, our former registry work-arounds are no longer working.

    Monday, May 14, 2018 6:01 PM
  • We too have this issue after the KB was installed. Remote execution of a CHM no longer works (nor does the registry modification to allow this as in past times). This affects all CHM files to my knowledge. For instance- copy "C:\Windows\Help\mui\0409\regedit32.CHM" to a network location and then double click on it. The content pane on the right will be blank.

    Monday, May 14, 2018 10:06 PM
  • We too have this issue after the KB was installed. This is a real problem for all our customers - we are developing an ERP-System installed and running over a network share. All these customers with updated Windows are unable to read our help system!!
    Thursday, May 17, 2018 8:09 AM
  • I can confirm that this issue exists and I have been unable to find a workaround that doesn't involve copying the .chm file to a local directory.

    Setting either the "MaxAllowedZone" or "URLAllowList" under the "ItssRestrictions" registry key doesn't done anything.

    Thursday, May 17, 2018 10:05 AM
  • I confirm also that this issue exists and that there is no workaround that doesn't involve copying the .chm file to a local directory.

    kb4103712 (win 7, win server 2008 R2) and kb4103721 (win 10, 1803)  show the same issue.
    Friday, May 18, 2018 9:36 AM
  • use NTFS Symlinks and you are done:

    mklink newlocalPath \\ServerPath /D

    and now you can open your server-side chm-files via newlocalpath

    Friday, May 18, 2018 3:44 PM
  • "

    use NTFS Symlinks and you are done:

    mklink newlocalPath \\ServerPath /D

    and now you can open your server-side chm-files via newlocalpath"

    and this works in running environments? Without shutting down any machine?

    Tuesday, May 22, 2018 3:35 PM
  • Tried it myself and it works! e.g.

    mklink /D c:\MyHelp \\myserver\helpfiles

    now you can access c:\MyHelp\SomeHelp.chm and you'll actually be reading \\myserver\helpfiles\SomeHelp.chm

    Wednesday, May 23, 2018 8:28 AM
  • I have the same problem since I switched to version 1803.
    For me, your solution is not an option,

    1. I have many clients I would have customizing
    2. The clients sometimes have several gigabit data that I would have to link.

    Does not anyone have another solution for this problem?

    Wednesday, May 23, 2018 12:00 PM
  • Hello, we have the same problem. I hope Microsoft will give an advice on how to fix this.
    Thursday, May 24, 2018 2:13 PM
  • We also open CHM Files from a share in our applications on thousands of clients. We are not able to force our customers to install everything local. Please @Microsoft, fix this and continue using the existing registrykeys or at least give us another possibility to white-list UNC paths.


    Friday, May 25, 2018 7:08 AM
  • @"CONNEXT Communication GmbH":

    1.) You don't need to take (and revert) "possession" (normal wording "Ownership") when using robocopy /B

    2.) Please warn users when recommending to revert security patches. What CVE will users be vulnerable for when applying your "solution"!?

    Monday, June 4, 2018 8:11 AM
  • Great find!

    This workaround does work, but due to the number of users we'd have to deploy it to, and how infrequently they access CHM files, I have decided to wait before implementing it.  Our users have gotten used to copying them local when they need to.

    Although I haven't tested it, I would think deploying it via group policy would not be very difficult.

    Tuesday, June 5, 2018 2:55 PM
  • I just installed the June updates for 1803 (17134.112) and network-hosted .chm files are still broken.
    Wednesday, June 13, 2018 1:13 PM
  • Hello,

    yesterday's patchday did not fix the problem to open .chm files via an unc path. I have only received feedback from Microsoft that the problem is known and a solution is being worked on. Long speech, the mistake still exists.

    For the transition solution described here, system files are exchanged, you (!) act on your own responsibility.

    You can solve this problem by copying the following files from unpatched systems (before the May update) to the corresponding System32 folders. For x64 systems, for 32 bit programs from which help (e.g. F1 key) is started via the network, the same procedure must be performed in the SysWOW64 folder:

    Windows 10/2016

    This repairs the direct call of the help via e.g. the Explorer


    Repairs the help function in 32 bit applications that call a CHM file in the UNC environment.

    Windows 7 / 8.x / 2008 r2 / 2012 r2



    You get the problem and the corresponding files relatively easily analyzed yourself. I found out the affected files with MJ`s Diagnostics

    Friday, June 15, 2018 5:10 AM
  • I'm glad to see this forum topic.
    I've been having this issue on our network also. Although there isn't a complete answer, it's identified what the problem is, and I appreciate it.

    I found, as Arne suggested, that copying the HH program files listed from an unpatched PC worked.

    So I'll be able to do this on any PC that needs help access, and hope that the issue is resolved in the July update.

    Certainly not an ideal solution, but much better than nothing.

    Friday, June 29, 2018 3:02 AM
  • We have this problem also.  I filed a support case with Microsoft back in May. 

    They have recommended the mklink solution, which does not help us.  That would require changing 1000 programs to point to the local directory. 

    They also had us test copying the files from an unpatched computer, which does work.  That however requires updating over 1000 computers.

    I have continued to press for a roll back of the change.  I received this reply from the technical advisor.



    I wanted to update you that the impact to your business has been shared with the concerned team and its under consideration.


    We understand that the problem has impacted your business due to a recent update. The decision to stop access to HTML help files over a network location was due to a Security vulnerability. While the product team is investigating the impact of the changes I cannot commit to you that we will be able to come up with a possible fix anytime soon nor do I have an ETA. This means that the decision to roll back the update is also not something I can commit on. In my view as this is a security vulnerability it may not be in the best interest to keep it unpatched by rolling back the update. I would not recommend it to you either to uninstall the update.


    With that said, I would like to assure you that we have done everything possible to get the right people involved and shared your business case. I am the highest point of escalation on a professional support incident and I wanted to reach out to you to provide my assurance on the same.


    Friday, June 29, 2018 12:03 PM
  • We also have the same problem. It would be great if Microsoft provides any advice.

    Wednesday, July 25, 2018 3:50 AM
  • Just installed the July updates on 1709 (16299.551) and 1803 (17134.167) and network-hosted .chm files are still broken.
    Wednesday, July 25, 2018 9:13 AM
  • Hi Dan,

    Have you had any reply or update on what Microsoft are going to do to allow *.CHM files to Open fully across the network?



    Thursday, July 26, 2018 12:34 AM
  • If you want to minimise the risk, I was able to get *.CHM Help files to open across the network with only replacing this file:


    I don't think it is necessary to update any other files 'regardless' if it is a 32 bit  or 64 bit machine.



    Thursday, July 26, 2018 1:44 AM
  • Wow, thank you for that Toni. That works great.
    It will simplify the process of taking ownership/permission and copying of files.

    That's a really good find :)

    Thursday, July 26, 2018 2:21 AM
  • Hi Toni,

    you made my day! Thanks a lot!

    I found out, that you can take the itss.dll from an unpatched Syswow64-Folder for both systems (32bit and 64bit).

    In my case I had to copie it into the SysWOW64-Folder (64bit) or into the System32-Folder (32bit).

    To replace it in the System32-Folder on a 64bit-System didn't work for me.

    Imported: You have to replace the ownership and give fullaccess für this file.



    Thursday, July 26, 2018 10:02 AM
  • Thank you for your comment, mighty pirate.

    I found that replacing 'itss.dll' in the System32 folder allowed me to access it via Windows.
    But in order to get it to work in our application, I needed to replace the copy in 'SysWOW64'.

    I'd imagine that's what Danny525 was talking about, that the 'SysWOW64' copy is for '32 bit applications that call a CHM file in the UNC envionment'.

    So replacing 'itss.dll' in both 'System32' and 'SysWOW64' is the workaround for me.
    It would be great to get this fixed by Microsoft.

    • Edited by RCCCWagga Wednesday, August 1, 2018 12:08 AM Slight alteration to text.
    Wednesday, August 1, 2018 12:07 AM
  • Known issue. The CHM issue is a casualty of a security hardening change in previous updates. 
    Retest with monthly currently scheduled to release in the September 2018 Preview that will go mainstream the 2nd week of October 2018.

    the September Preview KBs should contain release note text similar to

    • Addresses an issue that prevents the Microsoft Help Viewer from rendering HTML content inside a Windows Help .CHM file when the .CHM file is stored on a network location.
    • Edited by eventtrac Friday, September 7, 2018 8:04 PM
    Tuesday, September 4, 2018 11:45 PM
  • This issue was resolved by updates released the 3rd week of September 2018. 
    OS versions not listed in the table below won't be receiving a fix and will need to lead with a workaround like creating a symbolic link that adds a local shortcut pointing to the remote network location


    Resolving KB

    1803 / RS4

    KB 4458469

    1709 / RS3

    KB 4457136

    1703 / RS2

    KB 4457141


    KB 4457127


    KB 4457130

    TH1 / RTM

    KB 4457132

    Win8.1 / WS 12 R2

    KB 4457133

    Windows Server 2012

    KB 4458469

    Win7 / W2K8 R2

    KB 4457139

    Windows Server 2008

    KB 4458469

    Wednesday, September 26, 2018 8:06 PM