Missing SQL 2005 performance counters

My .net code kept complaining about uninitialized counters whenever it tried to access SQL Server, ‘The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly’. I opened Performance Monitor and sure enough the SQL counters had vanished. Now I’m not sure why that is, I did have some trouble with a recent service pack to Analysis Services so I’m guessing that’s what struck. With a bit of fishing around I managed to discover how to recover the counters;
 
Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn>lodctr perf-SQL2005sqlctr.ini
 

McAfee & SMTP, and are Virus Checkers the worst form of Virus?

Yesterday I was asked, "the application isn’t sending out emails, what is wrong?" The simple answer was, "you’ve installed McAfee Antivirus". The default installation this AV is to block the SMTP port, nice.

I’d like someone to do an impartial review of modern "protection" software. I recently read a review in MacUser about the hype of threats and I’m beginning to come around to their point of view. It’s not that I don’t see the value of such monitors but in my experience this particular tool seems almost as bad as the threats it reports to stop, I’ll explain why. What is the threat of a virus? Well there are many privacy related issues but for a modern company behind a hardware firewall I believe the two main risks are; Trojans and denial of service (DoS), both often resulting in a large amount of downtime to repair.  A Trojan is a risk as it could send important details to a basic HTTP site and could be very damaging, so I want my OS/Virus checker to stop things changing/installing executables (DLLs, scripts, et al) without my permission. DoS – where naughty software is doing something for its own gain (spamming) or just bringing a system to its knees for "fun". For DoS I want my OS/Virus checker to stop things changing/installing executables (DLLs, scripts, et al) without my permission, sounds familiar. Modern virus checkers do this so what is my issue? I wouldn’t have one if that is all they did. No they go the extra mile, they turn off useful ports (see SMTP above) without asking me, they inject script to help ensure scripts I run are ok (and those scripts then cause failures), they double check every file that is read (yes read as well as write). Not only that but one version (the one with lots of yellow) they can install loads of odd software and services I didn’t and don’t want – but can I get rid of the sub parts, nope.  Essentially the modern Virus Checker is one of the slickest DoS and Trojan installer you’re willing buy and install. DoS from a virus checker is no laughing matter. I regularly compile large projects and you can easily see the significant difference in speed with the checker on and off. So if I was to add up all the time lost in these minor DoS attacks from the checker against the number of infections * time to rebuild PC/PCs infected I wonder which would be worse? Now it doesn’t have to be as black/white as that. As I’ve said, if my checker simply attempted to stop nasty code getting on my machine then I’m pretty certain I would have a machine that does its day-to-day tasks efficiently with a very small chance of having nasty code installed.

I guess the moral of this story is choose your AV software carefully, consider what you deem to be an acceptable threat and learn the mantra, "options exclusion is your friend, options exclusion is your friend".
 

Microsoft Script Control as a Server Component

The Microsoft Script Control MSScript.ocx is a simple to use component that allows you to host VBScript scripts within your own application. Althought it has been implemented as a control it is very easy to use the underlying script component without involving any UI. However, I’ve recently learnt that things are not as they seem.
 
Using the Script Control as a server component, especially where concurrency is important, is not a good idea. The problem is that the control is written as Appartment threaded, what this really means is that it’s running as a Single Threaded Apartments (STA). So what? Well consider the following:
Clients A and B both invoke the Script Control at time X. The Script Control contains a VB script that takes Y seconds to complete. Client A is fractionally ahead of B and starts the running the VB Script. Now since the Script Control is running on a STA only one thread can be active at any one time. Therefore B is blocked until the control has completed running the script for A. The upshot of this is that the response time for A is (Y-X) whereas for B it is (2Y-X). For N concurrent users this would mean the Nth user would have a response time of (NY-X), obviously bad news.
 
So as nice and easy as the MSScript.ocx is to use, I would recommend staying well away from it where concurrent access is going to be an issue.