This blog is rapidly becoming a clearing house for Microsoft Network Monitor problems. The latest is an issue with Firefox - if you're trying to download add-ons or extensions for Firefox, and receive a "Download Error -228" in place of the desired coloured tabs or whatever, just disconnect MNM from the network settings and try again.
The acronym? Yet Another Microsoft Network Monitor Problem.
The solution? Works for me (which is an acceptable bugfix resolution code as far as I'm concerned).
Occasionally, I come across a problem that, while annoying, isn't really going to be any kind of a show stopper. I'll work at it for a while, then eventually decide that it's too much trouble, put it on one side and forget completely about it. Until I notice that whatever it was still hasn't been resolved, then I'll start worrying at the bit for a while again... and so on and so on.
One of these problems is the inordinate number of file handles that one of my system processes seems to use up over time. I'm referring to a process called 'audiodg', which is apparently associated with removing the DRM data that may be attached to various audio files before permitting other processes to play the file. It's another puny attempt to control access to data. (Hint to MS and various music publishers - someone, somewhere WILL crack whatever protections you use, and then it's all downhill from there on. Why waste your time, our resources and everyone's patience chasing a goal that's unobtainable?)
Audiodg is run as a protected process, to stop all those nasty hackers from breaking whatever DRM the publishers have added (see above). This means you can't easily see what it is up to. However, when it is listed as holding in excess of 4 million file handles after a day or so running, I think questions of exactly what it is up to become irrelevant: what interests me is how to stop it.
Fortunately, the cure is very simple - stop and restart the audiosrv service. This kills and recreates the audiodg process, with a nice clean no-handle instantiation. It doesn't stay that way, but it does at least work reproducibly.
Give the nature of the beast, info is not easy to find. I can't see anyone else complaining about this problem elsewhere, so perhaps there's something odd in my setup. I had put it down to the SoundMAX audio driver, but I'm not so confidant that this is the real culprit - surely if that were the case someone else would have seen and reported this. In the meantime, having just restarted the service, I'll probably forget all about the issue - until I notice the system running slowly and chewing up memory like there's no tomorrow again.
Two little snippets of knowledge picked up this week, both in answer to some issues that have been troubling me for some time. I offer them here on the offchance that they will be picked up by whatever search engines happen to come across these pages, and will prove of use to others seeking answers.
1) Microsoft Network Monitor 3.1 can be a right pain. There's some kind of problem between MNM and the Intel wireless network card in some laptops (specifically, in my case, a Dell Precision) which results in a runaway state on boot-up where the SYSTEM process chews up CPU time and memory usage goes up and up. Eventually, various peripherals such as a USB mouse and even the keyboard stop working and it's BRB (Big Red Button) time. Re-booting sometimes works, but equally often just allows the same thing to happen. I've had up to five reboots before I end up with a usable system. The trick (once you do manage to get logged in) is to disable to Network Monitor Driver in the adaptor network properties. All seems to work nicely then
2) Vista does nasty things to some 'shared' files. I have to report a very unusual source for this snippet - although we've been actively using Vista for over a year now, I hadn't seen either the problem or the solution until recently. The nature of the issue is that supposedly shared files aren't always - they can disappear when another user logs on to the local system. This is because Vista tries to virtualise data wherever possible, moving it from the normal 'Program Files' area to a hidden folder in the user's individual 'Local' tree. (There's one oddity which explains why we haven't seen this before - disabling UAC apparently prevents this behaviour. Although Microsoft would probably disapprove, this is exactly what we do as soon as we get hold of a Vista PC.) Where did I come across this? In Usenet, of all places in the uk.rec.motorcycling group, a source of knowledge that is unequalled anywhere else on the 'Net.
That's it for this week. If anything else of interest comes up, you can read it here - assuming the search engines do manage to find this.
