Tuesday, January 29, 2008

When the clipboard doesn't work across Remote Desktop

Every now and then, when I have a remote desktop connection open, the clipboard fails to copy across the sessions.  It's usually the remote to local copy that's borked.  It's pretty easy to fix, but I can never remember what I need to do to fix the connection.

Fortunately the Terminal Services Team Blog has got that covered.  Just kill and restart the rdpclip process in the remote session.   There was also a part two to that post that was pretty interesting.

[Edited on 1/30/08]
There is a command line way of resetting rdpclip, so you can roll up both steps as a batch file

taskkill /IM rdpclip.exe

rdpclip.exe



Thursday, January 24, 2008

Copying files with VS 2008's port-build event under Vista

I'm still working on my SmugMug plugin for Windows Live Writer. I've ported it from VS 2005 to VS 2008, that was trivial. I'm at the point where I want to debug the plugin while it's being loaded from Live Writer. Normally, this is pretty straight forward. You use the post-build event to copy the plugin's files to the Live Writer plugin folder. For my plugin, I used the following build event:

xcopy /D /R /Y "$(TargetDir)s*.dll" "C:\Program Files\Windows Live\Writer\Plugins"

The next step is to go into the Debug settings for the project and set the Start Action to Start external program, setting it to the path to the Live writer executable. On my machine, that would be:

C:\Program Files\Windows Live\Writer\WindowsLiveWriter.exe

With that set, all I need to do is to press F5 and my plugin gets built, copied to the Live Writer plugin folder, then Live Writer gets launched. Sounds good, but when I did a test build to verify the files would get copied, I got the following error message:

"XCOPY /D /Y /R "C:\dev\DotNet\LiveWriter\SmugMug4WindowsLiveWiter\SmugMug4WLW\bin\Debug\s*.dll" "C:\Program Files\Windows Live\Writer\Plugins\"
" exited with code 4. SmugMug4WLWPlugin

Code 4? I had to get Mr Peabody to look that one up for me. DOS 3.2 ring a bell? At any rate, exit code 4 for xcopy is "Initialization error (not enough memory, invalid syntax, path not found)". That actually was a clue to what the problem was, I was just missing the obvious. I tried pasting that xcopy command into a Take Command shell window and it ran without errors. So the syntax was correct, something was blocking it.

D'oh! I'm doing this under Vista. Joe User can't just copy files into "program files" space, that's no longer allowed. Only administrators have write access to "program files" and I'm running VS2008 without elevation. I run my Take Command shell as admin, so of course it can write to the plugins folder.

To get around this, I decided to punch a hole through Vista's default rights for that folder and give everyone and their dog full access to it. I tried doing it through icacl, but I wasn't getting the syntax right. So I just opened up explorer, selected the plugins folder, right-clicked and selected "Properties". I then selected the "Security" tab and then selected Users under "Group or user name". Next, I clicked the edit button, to bring up the edit dialog for the access rights. I selected "Full Control" and then clicked "Ok" all the way home.

That fixed it. VS2008 was able xcopy my plugin without any errors.

Friday, January 18, 2008

What do you mean my router has a UPnP security hole?

It's been recently made public that just about every consumer router is a security hole wide open and it's called UPnP.  That stands for Universal Plug and Play and it's a set pf protocols that allow netwrok devices to configure themselves on a network without requiring much, if any, human intervention.

The problem is that UPnP does not require any authentication and it is possible to create an Adobe Flash applet that will do nasty things to your router.  Like change the router's DNS settings so that when you visit your bank's website, you get sent to a phishing site that will take your login and password.  Or port forward to an external server, allowing your router to be used to attack other sites.  Or expose computers behind the router's firewall.

Since so many web sites use Flash to display ads, you would never see it coming.  Once you visited that page, the code would and your router is no longer solely under your comtrol.

Since many routers enable UPnP out of the box, you'll want to disable UPnP on the router.  It's usually an easy task, but you may need your router's manual to figure how to change your settings.

If you are using Windows Home Server, when you first configured it, it prompted you to allow it to turn on UPnP.  If you did that, go in and turn it off.  Right now.

Tuesday, January 15, 2008

How (and why) to increase the Windows Desktop heap size

Jon Galloway had a posting about issues that he came across when he opened too many tabs in IE7.  Apparently the Desktop ran out of heap space and Bad Things happened.  Jeff Atwood came across the same problem.  I remember reading Jeff's post back in October, but I didn't associate it with a problem that I was having.   

I was finding my self rebooting my XP dev box a couple of times a day.  The desktop was basically losing control and I couldn't do anything with the task bar or Start Menu.  Part of the problem was due to wonky display drivers from Nvidia.  I updated the drivers and the problem went mostly away.   But not completely.  I have a dual monitor setup, and I have a tendency to keep lots of things open on a desktop that spans both displays.

The longer I used Firefox, the less stable the system became.  I just became used to restarting Firefox.  One of the nicer things with Firefox is that you can restart it and come back to the same tabs loaded with the same pages.  BTW, Jed Brown's Restart Firefox Add-on is very helpful when you want to bounce FireFox and still have the same 12 tabs open.

At any rate, I was seeing the same symptoms that Jon reported.  There is a registry setting that you can edit that will allow you to specify the heap size reserved for the Desktop.  The default size is 3MB, everybody seems to agree that 8MB is the way to go.  The 3MB number was set for NT 3.51, back when we had a lot less memory in out machines.  This is only applicable for 32-bit versions of Windows, the 64-bit version do not have these memory limitations.

Kevin Dente documented how to bump this value.  To change this setting, you'll need to edit the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems and edit the "Windows" value.  This value is (as Kevin put it) a "big honkin' string" and you only want to edit one portion of it.  Look for the part that starts with "SharedSection".  It will have three numbers, the middle one will probably be 3072.  Change that to 8192.  On my machine, that part changed from "SharedSection=1024,3072,512" to SharedSection=1024,8192,512.  The YMMV rule is especially applicable here.  Remember to reboot after making this change.

The first number is the shared heap size common to all desktops.  The global handle table comes out of the shared heap.  The second and third numbers in SharedSection represent the size of interactive and non-interactive desktop heaps (services that interact with the desktop).  If terminal services are enabled, there may be a fourth number.  You only want to change the second number.

Tuesday, January 08, 2008

What's the deal with this .rbf file?

I was updating the installer to one of our applications and every time I ran it, it wanted to reboot at the end of the install.  This installer was installing a web application with some utility apps, nothing that should have forced a reboot.  I was running the installer inside a VMWare virtual machine of Windows 2003.

I've been using InstallAware for the last 3 months to author our installations.  It was being signaled by Windows Installer that it needed to do a reboot to complete the installation.  The question was why?  After a bit of digging in the help file, I found that I could use the "/l=filename" command line parameter to have the installer write to a log file.

I ran the installer one more time and copied the log file down to my dev machine to take a look at it.  It had roughly 9400 lines of Windows Installer chattering.  I started scrolling from the end of the file until I came to the line:

Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\3e1b7.rbf. Must reboot to complete operation.


What the frack is an RBF file?  After some googling, I learned that a file with the .rbf extension is a backup of an existing file.  I scrolled up some more and found a bunch of message like this:


Info 1603. The file C:\WINDOWS\system32\msvcr71.dll is being held in use by the following process: Name: VMwareService, Id: 1804, Window Title: '(not determined yet)'.  Close that application and retry.


The "Close that application and retry" tag means that installer would normally prompt the user to close the application that had the file in use.  If the process does not have a window title associated with it, then that prompt would be suppressed.  In my case, the processes were services and did not have window titles.  I found that documented in a few places, this post on the Windows Installer Team Blog being the most useful of them.


A few of the VMWare processes were also using msvcr71.dll and the file was in use.  OK, fine, but it was the same file.  Same bat-version, same bat-time.  Windows Installer should have had enough brains to determine that new file was the same file as current file and just skipped that step.  I don't think I ever had that problem with Wise for Windows (WFW had enough problems, but that's another story).  My guess is that it's an InstallAware issue, but I'm in the process of confirming that.


I did have a work around.  With the Install File MsiCode command, the dialog box for the command's properties has a check box labeled "Never Overwrite - do not install if another copy exists".  For msvcr71.dll, our code works pretty much each version that we have seen so far.  Setting that check box eliminated that reboot after every install.


Saturday, January 05, 2008

NPR broke the podcasting machinery

I like listening to podcasts on my Zen Vision:M player.  The Zen comes with a decent enough podcast tool called Zencast.  Zencast has an option to convert audio podcasts to video format.  They take the description of the podcast and display it as text in the podcast.  This makes it handy to see what is on a podcast by playing it for a few seconds.  The other advantage is that it categorizes them separately from the music, making it easier to drill down and locate the file to play.

Sometime in December, NPR made a change to their servers and is preventing the Zencast application from downloading any podcasts from NPR.  You get the message: "Unable to download due to a connection error."  It happened sometime between 12/3/07 and 12/04/07.  Other podcast sources work just fine, the problem is limited to NPR.org.   I can directly download NPR podcasts through a browser, but I lose the extra functionality provided by the Zencast application.  I'm not the only one getting this problem, I saw references to it here, here, here, and here.   The best guess is that the NPR server some setting that tells clients what functionality that they support and it's breaking the applications that actually check those settings.

Can someone from NPR please this?  I miss my Fresh Air and Car Talk shows.

Thursday, January 03, 2008

Windows Live Writer change from beta to 1.0 that affects plugin development

I've been working on a SmugMug plugin for Windows Live Writer on and off for the last few months.  The code is nearly complete, some other things came up and I had to put that code a way for a while.  Now I'm back on the code and I'm almost done.  While I was off doing other things, two things changed in my development environment.

The first change was the release of VS 2008.  I moved the code from VS 2005 to VS 2008 without any issues.  The other change that Live Writer left beta and there were some folder changes.  Your plugin code needs to reference the WindowsLive.Writer.Api.dll assembly.  The beta version lived in "C:\Program Files\Windows Live Writer\WindowsLive.Writer.Api.dll" and the release version lives in "C:\Program Files\Windows Live\Writer\WindowsLive.Writer.Api.dll".  It's a subtle path change, enough where you wont catch it at first glance.

If you were using the Post-build event command line to deploy your plugin for testing, make sure that you are copying to "...Windows Live\Writer\plugins" and not "...Windows Live Writer\plugins".

The SmugMug API rocks.  Having written and consumed various web services in different incarnations, I've very impressed with the layout and functionality exposed by the SmugMug API.