Showing posts with label Internet Explorer. Show all posts
Showing posts with label Internet Explorer. Show all posts

Monday, September 20, 2010

There was a problem sending the command to the program

I hate error messages like that. It’s both detailed and vague at the same. What command was being sent and what was the problem? Let me back up a few steps. A family member bought a new PC running Windows 7, for his home office. He works from home and accesses his work email account through Internet Explorer.  His email based on Domino Web Access, which I’m assuming is the web bit for Lotus Notes email.

When ever he was sent a document like an Excel file or Word file as an email attachment, he was unable to open the file.  He would double-click on the icon for the file, and Domino web page would spit out “There was a problem sending the command to the program”.  He has Office 2007 installed and we verified that it was working just fine.

If he tried to save the file from Domino, he would get prompted for a folder to store the file and he would try to save it is his documents folder. It went through the motions of saving the file.  No error messages, but the file wasn’t there. I repeat, there was no error message. I took a peek at the file system and found the file in an odd location. All the files that he had been trying to launch were in “c:\users\hisname\AppData\Local\Temp\Low\Domino Web Access\80\”. The “Low” part of the folder name tells us that Internet Explorer was redirected by Windows.

Starting with Vista, IE 7 runs with “low” privileges. The temporary files, cookies, and history folders are now in “low privilege” folders. Access to protected locations (root folder, documents, “my programs”, etc) is redirected by the operating system to the %LocalAppData%\Temp\Low folder. The folder virtualization that Vista/Win7 uses is pretty transparent the application. Unless the application checks for the file after it writes it (or knows about folder virtualization), it will not know that the file is in a different location. That explains why the files were not in the right location, but we still needed to figure out why they couldn’t be launched by the browser.

After a bit of searching, I figured out the problem. He just needed to add the webmail server site as a “Trusted Site” in the Internet Explorer security options. With Windows 7, he needed to do the following steps in Internet Explorer 8:

  1. From “Tools” menu, select “Internet Options”.
  2. On the “Security” tab, click “Trusted site” in the “Select a zone to view or change security settings.” panel.
  3. Click the “Sites” button.
  4. Under the “Add this website to the zone:”, enter the URL for the web mail site and click the “Add” button.
  5. If the URL starts with HTTP instead of HTTPS, make sure that the “Require server verification (https:) for all sites in this zone.” check box is cleared.
  6. Press the “Close” button.
  7. Press the “OK” button.

That will tell Internet Explorer that it’s safe to launch binary applications from the web mail application. It’s sounds annoying, but it’s just Microsoft trying to keep rogue web sites from running nasty programs.

Monday, August 30, 2010

Resolving "Navigation to the webpage was canceled" with Compiled HTML Help files (.chm)

I'm working with a SDK from a vendor that we have partnered with.  They provide the SDK as a download that I grabbed over FTP with Internet Explorer.  The SDK has a .NET assembly to use, some sample code, and documentation in a .chm help file.  It's all neatly bundled in a .zip files, nothing too esoteric.

Since Windows directly supports .zip files, I used Windows Explorer (Windows 7) to copy the files from the .zip file to new folder.  I then launched the help to examine some new functions the vendor had added for me.  The help file loaded up, but I couldn’t access anything.  It looked like this:

BlockedChm

At first I thought the file was corrupt, but then I realized what was going on.  With Windows Explorer, I selected the .chm file and right-clicked on it and selected “Properties”.

BlockedProperties

If you look at the section that is highlighted in green, you’ll see the text ”This file came from another computer and might be blocked to help protect this computer.”.  With Windows XP SP2 and later operating systems, the file’s zone information is being stored with the file as stream.  A stream is a separate resource stored with the file, just not exactly in the file.  Separate resource streams is a feature of the NTFS file system.  Since the .zip file had been downloaded with Internet Explorer, the .chm file was treated as if it had been downloaded directly. 

This is actually a good thing.  By default Internet Explorer will not let you run content from your local disk without your expressed acceptance.  Since the Internet Explorer rendering engine is used to render the pages of the .chm file, it’s going to block pages that came from the Internet Zone.

You have a couple of ways of fixing this.  One way would to disable the blocking of local content.  I don’t think that’s a safe way to operate so I’m not going to describe how to do that.  In the file Properties dialog, there is an “Unblock” button.  Click that button and you can remove the Zone block.

Another way would be to use a command line tool and remove the Zone Identifier resource stream.  SInce NTFS file streams pretty much invisible to the casual eye, you can grab a free tool to trip that data out for you.  Mark Russinovich’s Sysinternals collection of utilities includes a nice little gen called streams.  It’s a handy little utility.  It will list what streams are associated with a file or folder and you delete them.  Recursively and with wild cards too.  One of the thinks I like about Systinternal command line tools is that you can run them without a parameter to get a brief description of what it does and how to use it:

Streams v1.56 - Enumerate alternate NTFS data streams
Copyright (C) 1999-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

usage: \utils\SysInternals\streams.exe [-s] [-d] 
-s     Recurse subdirectories
-d     Delete streams

When I ran streams on my .chm file, I saw the following:

streams.exe SomeSdk.chm

Streams v1.56 - Enumerate alternate NTFS data streams
Copyright (C) 1999-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\dev\SomeSdk.chm:
:Zone.Identifier:$DATA       26

You can also get a listing of the resource streams if you use the “/R” parameter with the DIR command. To see the contents of the stream, you can open it with notepad with syntax like this:

notepad MySdk.chm:Zone.Identifier

That would display something like this:

[ZoneTransfer]
ZoneId=3

Any value of 3 or higher would be considered a remote file.  So I ran it one more time, just with the –d parameter and got this:

streams.exe -d SomeSdk.chm

Streams v1.56 - Enumerate alternate NTFS data streams
Copyright (C) 1999-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\dev\SomeSdk.chm:
Deleted :Zone.Identifier:$DATA

Once I did that, my help file was unblocked and ready to be used.

Monday, August 11, 2008

Why www.nbc.com wont load with IE7 on Vista (and how to get around it)

My kids wanted to watch the Olympic swimming events going on in Beijing.  Since NBC is streaming all the venues, I figures I would just fire up the web browser and wander over to www.nbc.com.   We have a “family” pc that everyone can use and it runs Vista Home Premimum (32-bit), with Service Pack 1 installed.  Since I knew that NBC was going to be using the Microsoft stack with Silverlight to stream the video, I figured I would have the least amount of headaches with Internet Explorer 7.  Wrong!

When I entered in http://www.nbc.com into IE, I got the following error: “Internet Explorer cannot display the webpage”.  I figured I mistyped the URL, that wasn’t it.  Out of the relatively small combinations that the letters N, B, and C can be arranged, I did have the right URL.  Could it be that NBC.com was done?  Nope, I tried “ping –n 1 www.nbc.com” and received the following

Pinging a1669.g.akamai.net [128.242.186.219] with 32 bytes of data:                               
                                                                                                 
Reply from 128.242.186.219: bytes=32 time=44ms TTL=55                                            
                                                                                                 
Ping statistics for 128.242.186.219:                                                             
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),                                         
Approximate round trip times in milli-seconds:                                                   
    Minimum = 44ms, Maximum = 44ms, Average = 44ms                                                




That tells us that their site is live and responding to requests.  Just for giggles, I launched FireFox 3 and entered in the URL.  Sure enough, that worked just fine.  What was the problem with nbc.com and IE7?  I did a search with Google (and Yahoo for a change of pace) and saw that a number of people were reporting the same problem.  No one knew the cause and the only resolution was “just use Firefox”.  Normally, that would be an acceptable answer for me.  Today, I’m feeling a bit cranky and I want to know what the problem is between nbc.com and IE7.  The odds are it’s something trivial on the nbc,com side.  We haven’t had any problems with IE7 on Vista before.



I did notice that a lot of people reporting the problem had Tablet PC’s. I don’t have a Tablet PC, it’s just an plain ol’ Dell desktop.  But I did install a Wacom Bamboo tablet and installing it’s drivers did activate some user input functionality in Vista that wasn’t there before.  Why would this affect the browser?  As it turns out, when Vista thinks it’s now a Tablet PC the user agent string sent by IE changes.



Here’s the typical user-agent string sent by IE7 for various operating systems.



For Windows XP SP2: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)

For Windows 2003 Server: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2)

For Windows Vista: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)



Note, these are the base strings, different applications can change or add to these values.  On my machine, the user agent has some information:



Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 3.5.21022; Tablet PC 2.0; Creative ZENcast v2.01.01)



That says that I’m running IE7 on Vista, with .NET 2, 3, and 3.5 installed.  Media Center extension are installed, it thinks it’s a Tablet PC, and I have Creative’s Zencast (a podcast download app).



Notice the text in bold, “Table PC 2.0”.  When that text is submitted to www.nbc.com as part of the user agent, the website is doing some sort of re-direct that is failing.  So we have what appears to the cause of the problem, now how do we fix it.  I tried faking out the user agent string with a download from Microsoft called the User Agent String Utility, version 2.  Don’t event bother with that one.  It opens up a new browser window that has been tweaked to report itself as IE 6.0 but that’s the only part of the user agent string that gets modified.  It still uses “Table PC 2.0”, so the problem still remains.



In theory, you can edit the list of items that get tacked on the user agent string by hacking at the registry.  With IE7, the list of fields added to the user agent string are defined as REG_SZ values in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform.  I tried removing “Tablet PC 2.0” from the list, but the OS kept putting it back in.  Plus, we really shouldn’t have to modify our systems, the problem is due to www.nbc.com not sniffing the user agent string correctly.



I did a little searching on the Internet and I found a working solution here.  Instead of using www.nbc.com as the starting URL, use www.nbci.com.  That site bypasses the user agent check and it allowed me to the live feeds of the Olympic events.  A very simple solution, but a typical home user would never figure it out on his own and just blame Vista for it.