A normal day

I thought that I would tell you what I am working on today to give you a snapshot of a typical working week. It is actually a relatively quiet time because of the summer holidays here in the northern hemisphere. Because these are issues for customers, I am going to describe things in fairly general terms to protect the identity and confidentiality of the customers.

In no particular order:

A customer wants a localisation (to French) for the fix in KB article 900822. That is proving a popular fix. The bug is a subtle one than can sometimes happen when an application that relies on timers is heavily stressed. Timers have always had a low priority because of the way that Windows works. About all that you can be sure of with a timer is that it won’t fire before the time that you have specified. The bug is that timers stop apparently firing. If a timer gets delayed enough that the next tick should have occurred in the past then the time until the next tick is negative. We don’t do a great job of waiting for a negative amount of time. The timer will actually fire eventually but it will be quite a few days late by then. Anyway, we have a fix for this.

A customer wanted use to change some fundamental things about how the linker works in Visual C++. I can understand exactly why they want it to work differently and I feel their pain. Sadly, we really can’t do what they are asking here though. It would be a huge rewrite though and we simply can’t do it for a released produce or Visual Studio.NET 2005 which is getting pretty close to release. Not next week or anything but we are not making major changes to it now.

A case where Winforms can get to a state where it can not show a modal dialog if it has shown the same one recently. Not a problem that a lot of people hit but we have a fix in progress for it. It is not certain that we will release this but I am 99% sure that it will happen. The fix is actually being done for a US customer but my European one will like it just as much.

An odd performance issue where a third party control is performing very poorly in a Winforms app running on a hyperthreaded Pentium 4. It is a bit of a mysterious one. It seems that there is a lot of contention on a critical section and it is worse on a hyperthreaded box. The nominal second processor is really a phantom and the end result is that rather than 2 processors running at the same high speed, it is more like 2 processors where one is much slower than the other. If the operating system is unaware of this, then the allocation of work to processors can work out in ways that gives you worse performance than you would want. In fairness, the critical section is one of ours and is associated with destroying fonts which is an expensive operation.

A scalability issue under Windows 2000. The customer has an immense number of assemblies loaded in to a single ASP.NET worker process. Most of the assemblies are repeated in different applications. I understand where the customer is coming from – they are trying to get application separation. It would work fine on Server 2003 but Windows 2000 was never designed for this and sadly it doesn’t work out so well. They are going to have to restructure things which is non-trivial but we will help all that we can.

A licence request from a customer who needs to ship one of our redist components to his customers. We get a lot of these requests and I am often handling 4-5 of them at any one time. There is no technical work in these, just admin and working with Dev/legal to get things approved.

A customer who gets AVs when compiling a project group in VC6 that contains over 5000 source files. There isn’t much that we can do to help here since there is no further QFE support for Visual Studio 6.0. The reason that it is failing is that we are not handling an error condition well and the stack gets corrupted. It isn’t a security issue because there is no elevation of privilege but it is a nasty problem that we can’t fix.

An ASP.NET application that seems to be returning blank pages once in a very long while. The jury is still out on what is causing this.

Another crash when compiling a VC application due to running off the end of the buffer and failing when handling the error. The project is incredibly huge and we didn’t test to quite the limits that this takes us to. We identified some changes that will enable the customer to compile but we would be hard pressed to make the environment stable for projects which are so much larger than anything that we have supported before.

A mixed VB6 and VB.NET application that sometimes locks up under stress. This is a complex case with multiple causes which we are trying to track down.

The next one is a little different. It turns out to be a timing issue with buttons on toolbars in Outlook when they are deleted from an in process COM server. Office application automation isn’t my area but it came to me when the original owner was out of the office due to illness. I managed to find a deterministic solution to the problem that the customer is currently testing. Timing issues are always tricky to work on because debugging them normally changes the behaviour. We like to fix them if we can but it is often hard to know exactly what went wrong. In this case, a small coding change in the in process DLL decoupled two objects so the timing of the object destruction was no longer critical.

A VB.NET bug where late bound COM clients fail to pick up the correct methods when the interface is derived from an overloaded class. We are working on a fix for it.

I also have a handful of optimiser bugs in Visual C++ 7.0 (Visual Studio.NET 2002). We have produced fixes for all of them and they are currently in the very last stages of testing.

I also mentor on a handful of cases a day which could come from pretty much anywhere in the world. As I said, with the summer holidays being here, this is a relatively quiet time.