Spectaculator emulator: Access Violation error with Saitek X52 Pro joystick

A very unusual one this, recorded here for the benefit of the half dozen other people on the planet who might stumble upon it while Googling the same problem.

This weekend I had reason to fire up Spectaculator 8.0, one of my favourite ZX Spectrum emulators but one which I hadn’t run in over a year. Surprisingly it crashed with an Access Violation error as soon as the emulation started.


Having had some compatibility problems in the past between earlier incarnations of Spectaculator and various security programs I began by disabling anything that might be misinterpreting the emulator as malware, then turning off various Windows services. I even disabled DEP in both hardware and software, all to no avail.

It then occurred to me that the only significant hardware or software change since the last time Spectaculator ran successfully was my joystick. I’d replaced my venerable Microsoft Sidewinder Force Feedback with a Saitek X52 Pro early in 2014 to maximise my enjoyment of Elite: Dangerous. So I unplugged the joystick and launched Spectaculator.

It ran perfectly.

To be fair, the joystick is perhaps something I should have considered earlier. I’d already suffered some problems with the drivers for this stick, which had caused system hangs when the hardware was plugged into certain types of USB3 port. I was also aware that Spectaculator likes to look for the presence of gaming hardware and assign it to default joysticks on the emulated ZX Spectrum.

I just hadn’t made the connection between the two.

The long-term solution turned out to be very simple: unplug the joystick, run the emulator, go to Tools | Options | Joystick and select (Disconnected) as the emulated joystick for Player 1.


Spectaculator now runs perfectly, with or without the X52 Pro connected.

I realise this is a very specific set of circumstances and that the vast majority of users will never see this compatibility issue. I know from discussions in other forums than not all X52 Pro users have suffered the USB3 compatibility problem (although one or two have) and that very few people have suffered issues as a result of Spectaculator’s default joystick mapping.

But just in case anyone, like me, suddenly finds a previously flawless Spectaculator installation falling over for no apparent reason, this is what turned out to be my solution. I hope it’s helpful to someone else someday.


Frustrating Microsoft dialogs strike again

This, Microsoft. This is an example of why people are annoyed by you.


Firstly, the redacted user account details are those of the account under which I’m logged in. There is no way an account should be asking for permissions from itself unless it’s for UAC purposes, which this clearly isn’t.

Secondly, why provide a More details dropdown that is greyed out and unclickable?

(To add insult to injury, when I clicked the gadget to close this window the More details dropdown actually un-greyed, and possibly even became clickable, for a split second before the window closed).

Seriously, is there someone at Microsoft whose job description is to produce the most frustrating and rage-inducing Windows dialogs imaginable? Because if there is he’s been doing a stellar job for over 20 years now and should be recognised as a leader in his field.

proXPN Windows startup problem – a workaround

I’m a big fan of the proXPN VPN service but for a while now I’ve had an annoying problem with the Windows client. It would not start automatically on my Windows 7 64bit machine when the Launch client on system startup option was enabled.

The option works by creating a Task Scheduler task to launch the client when the current user logs on, but it simply wouldn’t work as intended. Frustratingly, the Task Scheduler history would record that the task had completed successfully even though the client appeared not to launch. Even worse, executing the task manually by right-clicking and choosing the Run option would successfully launch the client every time.

The problem turned out to be one of simple timing. I can only assume there is a service or other OS-level dependency that the proXPN client needs to run, and without it the executable just exits silently. Delaying the execution by 20 seconds within the Edit Trigger dialog is enough to let the client launch successfully upon login.


Unfortunately this manual editing only works once because the client recreates the task each time it runs, overwriting the delay and causing subsequent launches to fail. Fortunately there is a solution to this, too.

The proXPN client uses a simple XML file to recreate the Task Scheduler task each time it is run. The file is proXPN_task.xml and is located in the same folder as the main executable. The default location is C:\Program Files (x86)\proXPN\bin\

To permanently add the delay to the proXPN login task, open this XML file in your favourite text editor (you may need to run as Administrator to ensure you can write the edited file back) and look for the following lines:

          <UserId>[your username]</UserId>

Inside that block, add the line that’s highlighted in red below:

          <UserId>[your username]</UserId>

This will add a permanent delay of 20 seconds to the client launching task.

Save the file and, if proXPN is already running in the Notification Area, exit and re-run it. If it isn’t already running, run it. This ensures that the scheduled task gets recreated with the new value.

Depending on the speed of your system you may need to increase the delay, or you may be able to reduce it. On my SSD-based system I’ve found that from a cold boot with automatic login a 20 second delay means the proXPN icon appears in the Notification Area a couple of seconds after the taskbar appears.

For faster or slower systems, or those where users always login manually, a bit of trial and error may be needed to find the ideal delay.