Who cares about slashdot. Anybody taking slashdot seriously is an idiot and treated as such.

Great stories... keep them up. Would love to hear about them.

Did anyone read "The Bug" by Ellen Ullman? Absolute worst case scenario - but the printing story made me think of that book.

not sure this is so bad. The advisory refers to specific registry keys, containing a variation of 'svrhost.exe'. If you don't have this key (I believe normal machines don't) you don't have the virus. Perhaps they need to clarify that the variation of 'svrhost' is not including 'svchost', but they don't actually say to delete 'svchost'.

But it's really far from the jdbgmgr hoax, as you genuinely do have a virus if the steps in their instructions are present on your machine.

So hoax? I think not

The registry key advice is ok, my heartbeat is with the comment "a variation of the same". As soon as they said those words, svchost.exe becomes a really easy variation on srvhost.exe.

I'm sure that the trojan's authors were counting on this confusion actually.

And the advisory DIDN'T say "not svchost". They said a variation of srvhost.exe. Which means that my mother will be sending me mail to delete that evil virus svchost.exe from my machine sometime soon.

Thanks! That's answered my question from Raymond's blog... (And now I've added yet another thing to read to my list; at this rate I'll never get any work done!)

Forgot the <a href=http://yesihaveabeard.blogspot.com/2004_03_01_yesihaveabeard_archive.html#107963321132301660>trackback.</a>

Good to have you here!

The problem really is that WNetAddConnection2 is a synchronous call that cannot be canceled. Ctrl+C handling is just a side effect.

You're right, but it was just an example. The comments I made above apply to EVERY console application that makes synchronous API calls. Like CopyFile. Or CreateFile.

If you like, replace NET.EXE with the internal "TYPE" command - try CTRL-C'ing a "TYPE \\DFFSDSDF\SDFSDFSFD\SDFSFSF". It gets blocked on a CreateFile API call while trying to do a DNS resolution of the server "DFFSDSDF", and the I/O can't be canceled because the CreateFile API is synchronous.

There's no way that the entire Win32 API set could have been made asynchronous, at a minimum, it would have caused MASSIVE waves of complaints on the part of our users, who would have insisted that we add synchronous versions of all the asynchronous APIs (for ease of use).

And then we'd be back where we are today, because the application authors would all use the synchronous version of the API.

And what about the user that uses "cat" under the Posix subsystem? That user isn't even running a Win32 application, they're running an app that's calling the synchronous Posix open() API with the non existant networked resource, which again is a synchronous API call and....

Btw, I'm using networks as examples here simply because DNS resolutions take time, and it's easy to generate a slow operation. This can happen with ANY synchronous operation.

I guess the question is then why are all of these processes (dhcp, lanman, etc) renamed to svchost instead of giving us their true names? Why keep the information hidden?

They're not. They're colocated in the same process.

Instead of taking up one process per service, the services are glommed together into the same process.

If you have the NT resource kit, you can use the tasklist command to find out what services are running in what process - use "tasklist /svc", it'll tell you what services are running in what process.

Also, Process Explorer from www.sysinternals.com can tell you. A handy near-replacement for the standard Task Manager, with a lot more capabilities. One of the top tools in my toolkit.

Good luck to Oliver and Sharron.

Wasn't MS-DOS / PC-DOS also a joint deal with IBM?

Did you just make this up, or did you read something someone else had just made up?