Archive for August, 2010

Office automation doesn’t work between different users – gives error Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80080005.

Thursday, August 26th, 2010

Yesterday, I was using an existing program on a new Windows 7 computer and when it was trying to send an email through Outlook, I was receiving the following error

Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80080005.

I tried it on my development machine (also Windows 7), and found that it worked fine.  Then I noticed that if I didn’t have Outlook loaded before trying to send the email, it seemed to work.  I realised that I was running my program as Administrator to temporarily work around some permissions problems, and that when Outlook was loaded normally, it was running as the normal logged in user.  I tried loading Outlook as Administrator and it worked fine, so I sorted out the permissions problem and turned off “run as Administrator” in the compatibility section of the program’s shortcut properties.  It still worked fine.  It looks like COM can’t operate between different users, which I suppose makes sense.

There may be other problems that can cause this same exception though – a quick search gave me a few other possible problems and solutions.

SagePay VSP Access becomes Reporting and Admin API but the protocol documentation is wrong!

Friday, August 13th, 2010

I just received an email this morning from SagePay to warn of their latest payment system update. For those of you who don’t know – SagePay is the (relatively) new name for ProtX since Sage bought them. ProtX developed a system back in 2008 called VSP Access, which was designed to allow you to programmatically access payment details for payments that have been put through using one of their payment systems (Form, Server or Direct (previously VSP Form, VSP Server and VSP Direct)).  For some reason, ProtX used to be downright secretive about this system and were difficult to get the information out of about it.  However, this is very useful for one of my clients as it allows us to confirm payments have actually gone through, keep track of refunds and spot any that somehow made it through without being logged by any of my systems (I don’t think that has ever actually happened, but it is a good double-check). They use that report for entering payments into their accounts software.

Anyway, back to the email I got today… SagePay are warning that they are upgrading their systems between 27th and 29th August and first of all, if anyone has IP addresses of their payment gateways hard coded, they need to update them (sounds like a bad idea anyway), and secondly, to say that if anyone is using the Reporting and Admin API then please check the Reporting and Admin API Protocol document (linked to in the email) as the code may need updating.

First of all, a couple of minor observations: –

  • They are allowing 14 days notice to make these changes.  That isn’t a great deal of time as many systems have a schedule of upgrades that are rolled out.  If anyone is in the middle of a big upgrade that could be a real pain in the neck.
  • The new name is rubbish – which marketing guy thought that “Reporting and Admin API” is easier to remember than “Access”?

However, that’s not the real problem.  The real problem came when I looked at the document.

The document says

All requests are sent to one gateway at address:
This immediately looked a little odd to me as I thought it isn’t very sensible to include spaces in the URLs, but I thought that it shouldn’t actually be a major problem, so I tried it.  I got a 404 page not found.  I had another look at the document and if you have a look at the links above, you’ll see that they actually link to 2 different addresses: – (Test) (Live)
Now these were actually the old addresses, so I thought I’d try these, but they are still reporting protocol version 1.01, when the new protocol is apparently 1.02.  This might be updated at the same URL, but I don’t want to rely on it.
A closer look at the document gives some other interesting problems: –
The XML field will contain the XML message, which always takes the following format:
<vspReporting and Admin API>
<vendor>Vendor Name</vendor>
<user>User name</user>
<other command specific parameters in here…./>
<signature>MD5 Hash Signature</signature>
</vspReporting and Admin API>
Now, I don’t claim to be an XML guru, but I’m pretty sure you aren’t allowed a tag name with spaces in, so that isn’t valid XML.  It actually looks to me like someone ran a search and replace, since the old tag was called vspaccess!  I think they might have been a bit too enthusiastic.  This would also make sense with the above URLs, but doesn’t really explain the protocol version problem that the old URLs return 1.01.
Since I ran out of other options and I didn’t want this to drag on, I decided to phone SagePay technical support.  A very nice lady there spent a few minutes trying to work out what I was talking about as she had obviously not heard of the Reporting and Admin API or VSP Access.  She managed to find the email that I had been sent and worked out where it had come from, so she forwarded my details on to the appropriate people.  I’ve just received an email back from them to confirm that the URLs are incorrect (big surprise!) and that they will send a new version of the document out with corrections.  They haven’t said when yet, but hopefully it will be in the next couple of weeks.

My PS/2 Doorbell

Thursday, August 12th, 2010

Over the last few years, we’ve been using a small battery powered doorbell made by a company called Friedland, but recently it has started playing up. I decided that since I have our file server next to our front door, it would be a fun project to connect a doorbell button up to the server, and set up the server to play a sound of a doorbell when it is pressed.

Since I didn’t want to waste any money on buying custom hardware to connect up a push button to the PC, and I couldn’t be bothered with too much complicated circuit design, I decided to cheat and disassemble an old (cheap) keyboard that I had lying around. It happened to be a PS/2 one, which is fine, since I’m using an A-Tech space saving keyboard on my server anyway which is USB, so the PS/2 port is free. The same principle would work just as well with a USB keyboard and of course that way you could probably have multiple ones plugged in, but then you might as well just assign different hot keys on the same controller if you want multiple buttons.

I elected to use the F11 key, since I don’t use it very much, especially on the server (which I rarely use directly anyway – it is mostly a file server, energy data upload for our Current Cost Envi 128 and it displays our CCTV cameras on a monitor by the front door). In hind sight, it is probably better to choose a different key, as F11 is usually used for making things like browsers full screen, but it isn’t such an issue for me anyway.

I discovered that the keyboard controller has 2 sets of contacts, numbered (I think) R1-R6 and D1-D12. When you press a key, it connects an R contact to a D contact, numbered depending on which key you pressed. I couldn’t really be bothered trying to trace the circuitry, so I downloaded a piece of software from and tried connecting different combinations of Rs to Ds until I found the right combination to give me F11. That only took a few minutes.

Once that was done, I screwed on a doorbell button that I bought for £3 on eBay next to my front door and ran the cable through the door frame. I wired up the 2 wires to the selected contacts and tested it. It appeared to be functioning as an F11 key correctly!

The next stage was dealing with the software. I realised that I was going to need a method of listening for global key presses in Windows, so I could use it as a hot key. Fortunately, I already had a project that I had downloaded from – this allowed me to catch the F11 key being pressed.

I set it up to play a sound file when it receives the key down event. However, I didn’t want someone pressing the doorbell 20 times a minute, so I added a variable to keep track of when the doorbell was last pressed and not trigger anything unless it has been at least 10 seconds.

The next problem was playing the sound. I had selected an mp3 file, which I was rather disappointed to find that My.Computer.Audio.Play does not support (it only handles wave files apparently). I dug out the code for the old MCI command mciSendString and used that instead, which works very nicely.

That was basically it. I set it up to auto-load on Windows starting, although you’d be better off running it as a Windows service really, but I couldn’t be bothered setting that up and my server is always logged in for the CCTV and the CurrentCost software anyway.

Other improvements I’ve thought of: –

  • I’m currently using a “ding dong” sound for it.  From a usability point of view, this may confuse people slightly, as they are used to a normal doorbell going “ding” when they press, and “dong” when they release, whereas my doorbell goes “ding dong” when you press.  I could split the mp3 file into “ding.mp3” and “dong.mp3” and catch the keyup event to handle dong in it, and put ding in keydown where the full sound is at the moment.
  • Windows service I already mentioned
  • Network messaging – when the doorbell is pressed, it sends a network message and PCs can display a message/play a sound in case eg. I’m listening to music at the other end of the house and I don’t hear it.  Equally, you could rig it up to send an email, SMS, twittweet or whatever you like, but I’m not sure why you’d want to.

Code: –

Public Class Form1
    Declare Function mciSendString Lib "winmm.dll" Alias "mciSendStringA" (ByVal lpstrCommand As String, ByVal lpstrReturnString As String, ByVal uReturnLength As Integer, ByVal hwndCallback As Integer) As Integer

Private LastPlay As Date?

    Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        AddHandler Gma.UserActivityMonitor.HookManager.KeyDown, AddressOf _GlobalEvents_KeyDown
    End Sub

    Private Sub _GlobalEvents_KeyDown(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyEventArgs)
        If e.KeyCode = Keys.F11 Then
            If LastPlay.HasValue AndAlso Now.Subtract(LastPlay.Value).TotalMilliseconds < 10000 Then
                Exit Sub
            End If
            mciSendString("play """ & IO.Path.Combine(Application.StartupPath, "doorbell.mp3") & """", "", 0, Me.Handle)
            LastPlay = Now
        End If
    End Sub

Extension Methods stop working!?

Wednesday, August 11th, 2010

I’m working on a solution where I have several different projects. Some of these projects are class libraries (DLLs) and some projects reference others. In some of them I have a number of extension methods.

I’ve noticed something strange happening occasionally. The extension methods in one of the class libraries stop functioning as extension methods for no apparent reason. This is even if they are called from within the same class library. It is usually after I have changed something, but not anything significant, and the namespace references all appear to be correct when I check. This isn’t just intellisense either – the build fails compilation.

The simple solution to this problem that I have found (which may solve other weird compilation bugs as well) is simply to clean the solution, close Visual Studio, reopen it and build again. This has worked every time that I’ve tried it so far.

This applies to Visual Studio 2010 Professional, and possibly 2008 as well, but I can’t remember if I had that problem then.

Why I’m not posting how to get .NET 4.0 working in Windows 2000

Tuesday, August 3rd, 2010

The most popular part of my blog is the posts that I have made on how to get .NET 3.5 (partially) working in Windows 2000, so why am I not continuing this with .NET 4.0?

The truth is that I originally did the .NET 3.5 approach for a specific project where a client of mine had a large number of Windows 2000 PCs. I wanted to be able to use .NET 3.5, and I didn’t want him to be saddled with the upgrade costs. However, since then, he has been gradually replacing those PCs with Windows XP and now Windows 7 PCs, until he only had 2 or 3 Windows 2000 machines left. I recommended to him that it was better for him to upgrade/replace the last ones rather than me trying to get .NET 4.0 working on the old ones, which probably wouldn’t be as cost efficient.

I realise that this might be a disappointment to some people who have still got lots of Windows 2000 machines out there. If anyone does come up with a way of doing it (possibly based on my .NET 3.5 approach), please let me know and I’ll post it up, crediting you.

Unhandled exception clr20r3 mxyabj2rsfg4uknkgmspj2kfpmzxhcc5

Tuesday, August 3rd, 2010

A few weeks ago, I hit a problem that an application that I wrote suddenly started randomly dropping out with an unhandled exception. I can’t remember all the specifics anymore, but I do remember that the event that was written to the logs (that can be viewed in Event Viewer in Administrative Tools in Control Panel): –

EventType : clr20r3
P9 : mxyabj2rsfg4uknkgmspj2kfpmzxhcc5

The most confusing thing about this was that I have a system built in to the application to catch unhandled exceptions, and this had been working fine in the past for a few years. I couldn’t understand why it wasn’t catching this exception.

What was even more confusing was that it was randomly affecting several machines in different sets of circumstances. I eventually managed to find something that would reliably reproduce the problem, but when I tried it on my development PC in the debugger, it worked fine (I still haven’t worked out why this is).

I initially thought that maybe it was because I had just upgraded to Visual Studio 2010 and tried to back-convert my application back to Visual Studio 2008, but the problem continued. I also tried using remote debugging to track down the problem, which also caused a lot of problems as the application still seemed to be dropping out even with the remote debugger running!

I eventually tracked down the problem using a Try, Catch clause around code which I knew would reproduce the problem. The exception was about a missing resource file. I hunted around and eventually found that the resx file for the error handling dialogue window seemed to have been excluded from the project, presumably due to some bug while it was being upgrade to Visual Studio 2010.

After I put the resx file back, I was able to see that the application was throwing an exception. My code for dealing with the unhandled exception had caught it and been throwing the other exception, which didn’t have anything to catch it, so the Common Language Runtime (or Windows?) killed it.

Edit: The actual exception type that was being thrown was System.Resources.MissingManifestResourceException