Showing posts with label Windows 7. Show all posts
Showing posts with label Windows 7. 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.

Thursday, February 25, 2010

What to do when a Windows 7 desktop icon has the wrong image

We are in the middle of rebranding our applications and as part of the rebranding, the icons for each application have been updated.  We are having lots of fun cramming Vista styled icons through ancient resource compilers, but that’s another story.

We provided a rebranded application to our QA tem for testing.  The first thing the QA manager did was to drag the app to her Windows 7 desktop, replacing the previous version.   Oddly enough, the image appeared for the icon.  I went back and checked the build process, that image was no longer there.  yet, it appeared on her desktop.  It also occurs with Vista as well.

I had originally posted how to do this by deleting the iconcach.db, but that is such a crude hack that I have pulled it.  After posting this message, I came across a much simpler mechanism. 

If you call SHChangeNotify(SHCNE_UPDATEDIR, SHCNF_IDLIST, 0, 0), from shell32.dll, this will cause the icon cache to be refreshed.  This happens in real time, no need to restart explorer or rebooting.  This is easy to call from just about every programming environment. If you need a stand alone app,  Helge Klien wrote a simple command line tool and posted it at Free Tool: Refresh the Desktop Programmatically.  I’ve added the SHChangeNotify() call to my installers, the users will never be bothered by this.

Saturday, August 22, 2009

Offload TCP processing to the network controllers under Vista, Server 2008, and Windows 7

After upgrading my home PC to Windows 7, I was decided to see if my motherboard/CPU combination support hardware virtualization.  You need hardware virtualization support if you want to run Windows XP Mode or Windows Virtual PC.  I have an XMD Athlon X2 with an Asus M2N-SLI Deluxe and I’m not sure if that combination supports hardware virtualization.  I’m pretty sure the CPU does, but I don’t yet yet know about the motherboard.

I decided to check the  Asus support forum to see that motherboard supports hardware virtualization and while reading through the forum, I found an a post about tweaking the network settings for a boost in performance.  The TCP/IP stack in Vista has the ability to offload some of the network processing to the network controller, if the network controller has that capability.  Out of the box, Vista disables that feature to prevent problems with controllers that don’t support that feature.

From what was posted in the Asus forum, this motherboard does support that feature.  This motherboard is based on the NVIDIA nForce 570 chipset, which included dual Gigabit LAN controllers.  If you are doing CPU intensive tasks, you can gain some performance benefit by offloading the TCP processing to the network controllers.

Vista refers to this setting as the “Chimney Offload State”.  It’s easy to check and set this value.  if you have a newish motherboard with a Gigabit speed network controller, this should work for you.

To change this setting, do the following:

  1. Open an elevated command prompt.  Either right-click cmd.exe and select “Run as Administrator” or press the Start button, type “cmd” and then hold the left shift and left control keys while pressing the enter key.
  2. Check the current status of the Chimney Offload state by running the following command:
    netsh int tcp show global
    The possible values for that state are: disabled, enabled, default
  3. Run the following command to enable Chimney Offload state
    netsh int tcp set global chimney=enable

Before making the changes, check your current broadband speed.  I like the one at speedtest.net, but the others are fine.  Then after making the change, check it again.  If the performance takes a hit, set the state back to it’s original value.  Not only did it work for me, I did get a slight, but measurable, download speed increase.

Before enabling Chimney Offload:

546138390[1]

After:

546142573[1]

These tests were run a few times before and after the modification.  I picked the average score each time.  That helps even out any existing network traffic that would affect the results.  Going from 17.42 MB/s to 18.70 wasn’t a huge increase, about 7%; but I’ll take it.  There are other settings that you can tweak.  Some are mentioned in the forum posting, and they are also documented in an article in speedguide.net as well.  You don’t often get a free lunch, this is a good one to take.  This setting works for Vista, Server 2008, and Windows 7.  I still don’t know if I can get hardware virtualization, but this was an interesting diversion.

[edited on 8/24/09]
As it turns out, my CPU and motherboard do support hardware virtualization, it just took a little work.

Wednesday, August 19, 2009

A work around for Delphi 2007/2009 with Windows 7 64 bit

I just installed Windows 7, 64 bit edition so that I could code and test against this new operating system.  Visual Studio 2008 installed and ran without any incident, but I hit a snag with Delphi 2007.  Delphi 2007 installed just fine, but it would die when you ended a debugging session.  An assert error would get thrown and after you cleared the dialog, Delphi would be terminated.
The error was thrown by bordbk105N.dll and had the following text:
Assertion failure: "(!"SetThreadContext failed")"
in ..\win32src\thread32.cpp at line 412
Continue execution?
That was followed by a “Yes/No” set of buttons.  It didn’t matter which choice you made, it was pretty much game over for Delphi at this point. After getting this happen 3 times in a row (even with Delphi launched with “Run As Administrator”), I decided to check the Internet and see if this was unique to me and if there was a fix.
I checked Google and found a few hits.  One of them led me to a blog written by Olaf Monien, a German developer with close ties to the Delphi R & D department.  His post, “Delphi 2009 / Windows 7 / 64 bit Debugger Crash Workaround”, described the issue in great detail.  Apparently an incorrect call is being made to the SetThreadContext API call.  The debugger dll has an assert call based on the return value SetThreadContext().  It’s odd that production code went out with asserts enable, that’s usually used during testing.  Some people traced through the debugger code and found that if a single byte is changed in the dll, you could get by this error.  This byte changes the logic so it ignores the return code from SetThreadContext() and never hits the assert code.  You can read about how they came up with that idea here.
An enterprising programmer named “LordByte” wrote a handy little utility that will patch the debugger dll for both Delphi 2007 and Delphi 2009.  Olaf is hosting the patch tool on his blog and This file found a permanent home at Embarcadero and you can download it from Delphi_2007_2009_WOW64_Debugger_Fix.zip.  This works but you now have the added risk of actual errors being returned from that call to SetThreadContext() being ignored.  Since the alternative is an unusable Delphi, it’s a risk I’m going to have to take.

[Edited April 22nd, 2013]
While I no longer use Delphi, I hate to see a broken link.  I updated the download link for the debugger patch to it's current home at Embarcadero.