Environment
I’m running XP SP2 with the Microsoft updates set so that I can review them before I install. All security patches were installed. I use Zonealarm Pro which I’ve had since 2003 and which is thoroughly configured. And - of course - I’ve been an Avast user for about the same time.
The Problem
Four days ago something started to kill the Remote Procedure Call which then triggers a 60 second count-down before system close down.
Steps to date
1
I ran :- services.msc /s - and tried to open the RPC Properties window so that I could change the failure setting to ‘restart the service’ but the properties window won’t open
This means that I can’t keep the system up for very long. Oddly, in Safe Mode the
countdown starts immediately - before I have logged on at all
2
I 've installed a SCSI hard drive and launched another iteration of XP. (This is what I’m using now). I have searched for msblast.exe, I’ve run Symantec’s ‘FixBlast.exe’ and I’ve run Microsoft’s Malicious Software Removal tool. As far as these programs are concerned I’m clean. (Bear in mind, though, that they’ve not been run from within the infected program)
3
I can get at HKLM/System/Contol set 001/Services/RPC Ss on the infected OS and open the FailureActions binary but I don’t know how to change these setting to ‘Restart Services’ (I’ve looked at the binaries in the OS I’m using but they were totally diferent
The real mystery is that I’ve no idea what it actually causing RPC to fail - and I don’t know how to start looking. All my discs haver been thoroughly scanned (from within this OS) and no-one has found anything suspicious.
I suppose you can’t even access the Windows Events logs or any other info in your computer that could help us to help you…
Can you boot from another computer having this ‘problematic’ HD installed as a slave drive, scan it with a-squared, ewido, avast, etc.?
Really I think this will be a workaround. RPC is a completely necessary Windows service. I think this ‘restart’ won’t even work… It can’t fail at the first.
So, better will be trying to solve the problem (why is it crashing…) and not just ‘set to restart’ the service.
Many many thanks for your help. I’ve not worked out how to do the neat quotes yet but here are my responses to your points
“I suppose you can’t even access the Windows Events logs or any other info in your computer that could help us to help you…”
I can open ‘eventvwr.msc’ using ‘run’ in the task manager. I then have about 2 minutes before RPC is killed and the NTAuthority close-down sequence starts. But while I can see the log list views I can’t open the properties windows.
Certainly Avast is throwing up a whole sequence of error alerts (id 90) in the antivirus log
“Can you boot from another computer having this ‘problematic’ HD installed as a slave drive, scan it with a-squared, ewido, avast, etc.?”
This is really what I’ve done. I plugged in an Adaptec 2940 and hooked on a SCSI hard drive. I then set the boot sequence to launch from the SCSI but all the other dives are still here and visible. But I don’t know how to look at - let alone edit - the registry of the infected OS
Really I think this will be a workaround. RPC is a completely necessary Windows service. I think this ‘restart’ won’t even work… It can’t fail at the first.
So, better will be trying to solve the problem (why is it crashing…) and not just ‘set to restart’ the service.
I totally agree. But, if the service was restarted it might give us more time to find the culprit
Event Viewer
I’ve looked at the application folder and managed to get a screeshot of the start of the problem on November 15th which I attach. The properties windows wont open because RPC is dead so this is as far as I can get.
Next Step
I suspect that this is a rogue program. Since it will - after a while - kill the RPC before any account is selected it must be burried deeply in the boot-up seqence. Certainly the fact that it kills RPC immediately in Safe Mode supports this idea.
I don’t know if it possible to view any of the critical system information in an OS that is dormant. If I could look at the dormant registry or eventlog I might find a clue as to who, actually, is the culprit
