Skip to content

A strategy for dealing with support departments

I’ve bought three PCs from Tranquil PC over the past couple of years. They’re pretty good but while the newer ones are built using Intel Atom motherboards the early ones were built on Jetway boards with VIA processors and aren’t as reliable. I have one of the earlier ones and it took Tranquil three attempts to deliver one that even powered up. After two years of 24×7 operation it’s now died and I’m fairly certain that it’s the motherboard that’s failed.

So I opened a ticket with Tranquil’s support team. The initial response was prompt and asked me to use their Q&A based diagnostic tool to diagnose the problem. It only took two questions to confirm that it was a dead motherboard. I updated the ticket to indicate that the tool had confirmed the problem was a dead motherboard. After a couple of days without any follow up from Tranquil, I updated the ticket asking if someone could respond.

I checked a few days later and there still wasn’t a response. So I updated the ticket again. And again a few days later. And again. By now it was 12 days later.

I tried a different tack. I opened a new ticket to complain that the original ticket was being ignored. My intention was to open a new ticket every day until Tranquil responded. I was guessing that the performance of the support team is probably measured by the number of open tickets it has and how quickly a ticket is closed. It’d be difficult for them to ignore me opening a new ticket every day just to remind them about the original ticket.

Seems like I guessed right – four hours after I opened the first new ticket I got a response.

:-)

Tagged
2010 02 04 General Comments (0) Permalink

‘Too many connections’ with MySQL .NET Connector

I was Googling for some info on MySQL the other day and stumbled across a few ‘bug’ reports from developers experiencing a ‘Too many connections’ exception when using the MySQL .NET Connector.

This sounded familiar so I checked some code that I wrote about six months ago and confirmed what I thought… It’s simply that calling the MySqlConnection.Close() when you’ve finished with the connection is not enough. You need to call its Dispose() method too.

While calling Dispose() ought to be obvious, Microsoft’s SqlConnection implementation is much more robust and allows developers to get away with some poor programming practices. I’d guess that quite a few developers write code for MySQL that’s very similar to code they’ve previously written for SQL Server that appeared to work well enough but then this problem shows up with MySQL.

If you wrap up database functionality in a class that uses an instance of MySqlConnection the you probably need to implement IDisposable and call Dispose() on the MySqlConnection instance in your class’s Dispose method. For example, I have a base class that’s used for calling stored procedures and manages its own connection to the database:

    public abstract class StoredProcedureExecutor : IDisposable
    {
        private MySqlConnection connection;
        ....
        public void Dispose()
        {
            this.Dispose(true);
            GC.SuppressFinalize(this);
        }
        ...
        private void Dispose(bool disposing)
        {
            if (disposing)
            {
                if (this.connection != null)
                {
                    this.connection.Dispose();
                    this.connection = null;
                }
            }
        }
    }

 

Tagged
2010 02 01 Development Comments (0) Permalink

Visual Studio: The problem with Settings GenerateDefaultValueInCode

When you use Visual Studio to create your application’s configuration settings, each setting has several properties associated with it. The Name, Value, and Scope properties will be familiar to anyone who’s used the Settings editor but do you know exactly what GenerateDefaultValueInCode does and whether you should set it to True or False ?

As its name suggests, when GenerateDefaultValueInCode is set to True the Settings Designer generates code to return the value specified in the editor when the runtime configuration file doesn’t have an entry for the setting.

At first this might seem like a useful feature but I’ve come to the conclusion that it’s a liability and often hides configuration issues in deployed code. You might think that you’d quickly spot this type of configuration problem but I spent a couple of hours yesterday debugging a .NET Remoting application before guessing that it was probably a configuration file setting issue. It was a guess because nothing in the exception stack trace clearly indicated what the problem was.

In this particular example, the code consisted of the following components:

Vitality.PAS.Interface – A .NET remotable class that implements an interface to a data store
Vitality.PAS.InterfaceServer – A class that creates a server remoting channel for the Interface class
Vitality.PAS.InterfaceService – A Windows Service that hosts the Server class
Vitality.PAS.TestApp – A test program that acts as a client for the Interface

The management of the configuration settings is a little bit confusing. For example, the TestApp’s configuration file needs the settings used by the client side code in the Interface component. The Service component’s configuration file needs all the settings used by the InterfaceServer component and the settings used by the server side code in the Interface component.

Because GenerateDefaultValueInCode was set to True for all these projects the code worked even though the configuration files were not correctly set up. However, because the values generated in the code were those that were specified during development the deployed code was not behaving as expected.

It would have been possible to get the code to work as required by correctly setting up the various configuration files but the fact that the code doesn’t fail when configuration file settings are missing seems like bad practice. So, I changed GenerateDefaultValueInCode to False for each setting in all four projects.

Tagged
2010 01 26 Development Comments (0) Permalink

NUnit and application configuration files.

When running unit tests your code isn’t going to be loading configuration values from the configuration file normally used. The config file used is always located in the same folder as the executable and has the same name as the entry executable but with ‘.config’ appended.

So when running your unit tests, what’s the filename and location of the config file your code is going to use ?

If you Google this you’ll find various answers depending on which version of NUnit you’re using, whether you’re running the tests using the GUI test runner or the console test runner, etc.

My test fixture setup copies the application’s config file to the location and filename that NUnit will use. I tried hardcoding the target filename but after trying the various suggested filenames without success I realised that there’s a much better approach: let the .NET framework tell us what the path of the file its using is.

The AppDomain.CurrentDomain.SetupInformation.ConfigurationFile property provides the path of the configuration file that is being used. So, the test fixture setup code needs to copy the project’s config file to this path:

string nunitConfig = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;
string appConfig = Path.GetFileName(Assembly.GetExecutingAssembly().Location) + ".config";
File.Copy(appConfig, this.nunitConfig, true);

One thing to watch out for though – don’t try specifying a fully qualified path for the application configuration file using the executing assembly’s location. The problem is that NUnit runs your code in a separate AppDomain from a copy of your assembly in temporary folder. Although NUnit copies your assembly to the temporary folder it doesn’t copy the config file. However, the current working directory is set to the folder where the target assembly resides (e.g. MyProject\bin\debug) so the config file can be referenced using an unqualified path (i.e. just the filename).

Tagged
2010 01 22 Development Comments (0) Permalink

Why fight it ?

With the recent release of Windows 7 and the imminent release of Visual Studio 2010 it feels like the merry-go-round has started up again… Well, it never stops does it ?

I’m sure that many developers feel anxious from time to time, if not all the time, about the rate of change. As we get up to speed on the latest version of C# and the .NET framework Microsoft throws a yet another version at us.

A few years ago I made a conscious decision to learn to live with it. Worrying about it wasn’t going to help…

I’ve just finished reading ‘Indian Larry: Chopper Shaman’ and was interested to read Indian Larry’s attitude to change. Talking about the question mark logo that he used on his bikes:

That’s my life’s logo because I don’t know what’s going on. Roll with the mystery, life is uncertain… just be comfortable with that. Why fight it ?

Tagged
2010 01 20 Comment Comments (0) Permalink

A Windows Service has a current working directory of C:\Windows\System32

A warning for the unwary – you might expect that your Windows service is started with its current working directory set to the location of the service executable but it isn’t – it’s set to the Windows System32 directory.

There’s no reason why you shouldn’t change the working directory if it makes sense to do so. As an example of why you might want to, this is how I stumbled across this issue:

The project I’m currently working on uses a Windows service written in C# that communicates with a proprietary medical data store via a Win32 DLL. The .NET Framework successfully locates the DLL when my code calls the functions in the DLL via P/Invoke. I’m guessing that the framework is locating the DLL using a technique similar to the one it uses when probing for referenced assemblies, i.e. it looks in the directory where the entry assembly was loaded from.

The problem I encountered is that the code in the DLL (PASData.dll) looks for its configuration file (PASData.inf) in the current working directory, i.e. C:\Windows\System32 and fails to find it there.

I added the following code to the OnStart() method of the service to set the current working directory:

string assemblyLocationFolder = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
if (string.Compare(Environment.CurrentDirectory, assemblyLocationFolder, StringComparison.OrdinalIgnoreCase) != 0)
{
    Environment.CurrentDirectory = assemblyLocationFolder;
}
Tagged
2010 01 18 Development Comments (0) Permalink

Windows Server 2003: UPS protected server drops off network

I have a small server running WIndows Server 2003 and protected by an APC BackUPS CS 500 UPS. The server runs headless and is only occasionally accessed using RDP.

Recently the server has started disappearing off the network. It’ll run OK for a few days but then can’t be located on the network although it’s still powered up. I assumed that it was blue screening or something similar but because it runs headless it was impossible to know. Powering it off and on always brought it back on line and the event logs didn’t show anything unusual. In fact, the event logs seemed to indicate that the server was operating normally when it became inaccessible.

The first rule of problem diagnosis: what’s been changed ? Nothing. Sure ? Hmmm, well I did recently install new drivers for the server’s two NICs…

I spent an hour yesterday trying to work out if there was anything wrong with the way the server was configured that might cause the problem. Eventually, I noticed in the Control Panel Device Manager that the active NIC was configured with the Allow the computer to turn off this device to save power setting. Normally, I’d only expect to see this setting set on a laptop so why was it set on by default on this server ?

My suspicion is that it’s because this server is attached to a USB enabled UPS. Windows Server 2003 supports this type of UPS by treating it as a battery based power supply in exactly the same way as Windows handles laptop power management.

I haven’t proved this yet but I strongly suspect that the USB enabled UPS has fooled Windows into thinking that this is a laptop type machine and so when I reinstalled the NIC drivers the Allow the computer to turn off this device to save power setting has been set on by default as would be appropriate for a laptop. 

Typcally, I get a couple a couple of brown outs a week where the voltage drops enough for the UPS to kick in. I’m guessing that as soon as Windows 2003 identifies that it’s running on battery power the NIC is powered off because of the Allow the computer to turn off this device to save power setting and the server ‘disappears’ off the network.

I’ve changed the Allow the computer to turn off this device to save power s setting so now I need to give it a couple of weeks to see if the problem goes away.

The other change I’ve made is to configure the two Alarm Action settings on the Alarms tab of the Power Management control panel applet. Each one now calls a task that executes a batch file that writes a date and time stamped message into a log file and also issues a syslog broadcasts with the message. The first alarm, the Low Battery alarm, simply logs the fact that the alarm has been triggered. The second, the Critical Battery alarm, logs the alarm and shuts the server down.

Broadcasting the power alarms seems like a good idea anyway but logging the alarms should help to confirm if the problem has now been resolved. 

Tagged
2010 01 14 Hardware Comments (0) Permalink

More NETBIOS name lookup problems and port 137 weirdness

Back in May last year I blogged about why port 137 needs to be open for UDP requests if you want NETBIOS name lookups to work.

I bought a new laptop earlier this year that I use every day for software development. Right from the start I’ve never been able to connect to its network shares or to RDP to it. This has never been a problem because I usually work on this machine and connect to other machines rather than the other way around. I’d briefly tried to find the cause of the problem a couple of times without any success. It wasn’t much of an inconvenience but, out of curiosity, I kept meaning to find out what the problem was.

Over the Christmas holiday I had the time to do this so I started looking. I expected to find that port 137 was blocked and that I simply needed to set up an exception for it. It was blocked but in a rather strange way…

I found that File and Printer Sharing was enabled on the Exceptions tab of the Windows Firewall configuration applet. As this includes an exception for port 137 I looked for the cause of the problem elsewhere but couldn’t find anything. Eventually, I came back to the Exceptions tab again, selected File and Printer Sharing item, and then clicked the Edit button. It was immediately obvious that something was amiss:

Windows Firewall - Port 137 

Two questions: Why was the Scope for UDP 137 different from the other exceptions ? And, how was it different ?

The second question was easier to answer. Clicking the Change Scope button displayed this:

Windows Firewall - Port 137 Custom

Instead of being set to My network (subnet) only as I’d expect the scope was set to a specific IP address.

I can’t understand how this happened. I certainly wouldn’t have deliberately configured it like this. At first I wondered if it was some weirdness that happened during Windows installation. But, the more I thought about it, the more I began to suspect that it’s the result of a poor choice by me to a prompt by Windows. I’m guessing here, but I think Windows must have prompted me at some point to allow a connection request and offered a choice of any computer, local network, or a specific computer, and I selected the last option thinking that this was a single request and not realising that it was going to set an exception policy that I’d have to live with.

Of course, this is easily corrected (by clicking the My network (subnet) only option and clicking OK) but finding the cause of the problem was less obvious than I’d expected.

Tagged
2010 01 12 Uncategorized Comments (0) Permalink

Modern technology really is better

I recently bought a 1941 Indian Scout. I already have a Buell XB9S Lightning. Both bikes have ‘old technology’ pushrod air-cooled v-twin engines but where the Scout relies on a carburettor and a contact breaker type ignition circuit the Lightning has an ECU managed fuel injection system.

The Scout’s engine is essentially a 1932 design that Indian continued using until it went out of business in 1953. The Lightning’s engine was designed by Harley-Davidson in 1957 but the Buell version uses modern materials in its construction and Buell’s own engine management system. One of the more obvious differences between the 1941 Scout and the 2003 Lightning is that the Scout makes a little over 20HP from its 750cc engine while the Lightning makes over 90HP from its 984cc capacity. The specific outputs (i.e. normalised to 1000cc) are 30HP and 94HP. So the Lightning’s engine is making over three times the power of the Indian despite using a very similar design of engine. Modern versus old…

Other than power how much difference does all the modern technology make ? Well, here’s a side by side comparison based on a journey I needed to make into town earlier today…

One thing to note is that while most modern motorbikes have a single twistgrip for the throttle that is spring loaded to return to the closed position, the Scout has two non-spring loaded twistgrips. One controls the throttle and the other controls the ignition advance/retard. Because these twistgrips are not spring loaded they stay in whatever position they have been set to.

To start the Scout you need to:

  • Open the fuel tap from the main petrol tank
  • Set the ignition switch to off
  • Set the ignition advance/retard twistgrip to one third retarded
  • Set the throttle twistgrip to one quarter open
  • Set the carburettor choke to fully on
  • Use three kicks to prime the engine
  • Set the choke to the start position (one click up from full choke)
  • Turn the ignition switch on
  • Give the kick start a single kick
  • It’ll usually start first time and then you need to adjust the throttle so that it’s just slightly open for a fast tickover and quickly move the choke up one more click to the ‘run (cold)’ position.
  • Leave the bike running for at least five minutes. As soon as you see dark smoke from the exhaust you need to move the choke up one final click to the normal run position and ease the throttle to the fully closed position.

That’s all there is to it. ;-)

While the bike is ticking over the oil return needs to be checked by removing the oil tank filler cap. If the oil is returning from the scavenge pump in the sump then it’ll be pulsing out of the return pipe. If it isn’t, the ignition needs to be turned off immediately to stop the engine. The pump needs to be primed by forcing oil down the return pipe. The engine can then be restarted and the oil return checked again.

Halfway into town the Scout started hesitating and then cut out. I pulled over and tried to restart it. With a hot engine this needs a slightly different procedure:

  • Fuel tap on
  • Ignition switch on
  • Choke in the normal run position
  • Ignition advance/retard to between one third and one half retarded
  • Throttle to half open
  • Give the kick start a single kick
  • As soon as the engine catches quickly twist the throttle closed otherwise the engine will scream up to maximum revs in less than a second.

If you try to kick the engine over with the ignition advanced it’ll kick back and probably backfire through the carburettor too just for good measure. I never made it in to town as there was some dirt in the carburettor that caused the engine to repeatedly cut out and I counted myself lucky to get back home with it only cutting out once more while I was riding it. I can’t blame ‘old technology’ for this particular problem but there’s no getting away from the fact that the Indian’s 1930s technology is dirty, smelly, inefficient, and not completely reliable. The flip side is that it’s simple enough that it can often be easily fixed with little more than a few spanners and a little bit of know how.

I still needed to get into town so I wheeled the Scout back into the garage, remembering to slide a large piece of cardboard under the engine to catch the oil that it always leaks after it’s been running, and got the Lightning out.

To start the Lighting:

  • Turn the ignition on
  • Make sure the Kill switch in the run position
  • Push the starter switch

The bike always starts at the first push of the starter switch. The ECU lets the engine spin for at least three full revolutions before generating a spark. This ensures that the engine has enough speed and momentum to start easily and for the starter gear to disengage cleanly from the flywheel. The engine needs to be left for a few minutes to warm up. That’s it… Compare this with the procedure listed above on starting the Scout!

I rode the Lightning into town, parked up, visited the shop I needed to, went back to the bike, started it, and rode home again. No dramas. No smoke, no oil, no petrol. No smell.

I’ve never previously started and ridden the two bikes back to back like this and afterwards I couldn’t help making the comparison.

Tagged
2010 01 07 Comment Comments (0) Permalink

Microsoft Virtual Server: The virtual machine could not be started. The account name and password are invalid.

If you copy a .vmc file and modify it using a text editor you’ll probably get this error message when you try to start the machine:

The virtual machine could not be started. The virtual machine could not be started. The account name and password are invalid.

(Note the repetition of the first sentence in the error message.)

The problem is that Virtual Server assumes you’re up to no good and invalidates the stored password for the credentials specified in the .vmc file.

The solution is to click the machine in the Virtual Server Administration web site and select the Edit Configuration item. Then select the General Properties option, then re-enter the password, and, finally, click the OK button.

The machine should now start.

Tagged
2010 01 04 Environments Comments (0) Permalink