Damn KB890830!!! Arrrrggggghhh.

[N. Miller]

I have spent almost as much time troubleshooting a failure to run of the
Malicious Software Removal Tool on two computers, as it would have taken to
"scrape and build".

Case A: HP Pavilion m7590n. Originally shipped with Windows MCE 2005 SP2
upgraded to SP3. MSRT for August 2008 triggers a system restart, and all
updates failed. I finally ran "Custom", and installed each of 9 updates one
by stinking one. When I hit KB890830, as the installation progress bar was
marching across the screen, there was a very audible "click", as something
tripped the P.S., and system shut down, and restarted. Went into file system
check mode, and came back still wanting to run the MSRT.

Case B: HP Pavilion 6745C. Originally shipped with Windows Me, obtained a
Windows XP Home Edition SP2 upgrade pack from Fry's Electronics, and did a
clean install on NTFS partitions. Added SP3 before setting up the
applications. I let it run with 13 "Critical Updates" to work on, came back
to find it had rebooted spontaneously. Went back to the Windows Update site
only four of the updates had installed. Went to "Custom" mode, and installed
all but KB890830. Installation was normal. However, as with Case A:,
KB890830 triggers a shutdown before it has begun to run. At this time, MSRT
has not been run on the Pavilion 6745C. I can't force it into Safe Mode the
same way as with the Pavilion m7590n F8 key. Too tired to continue at this
time been 12 hours since I began screwing around with this issue. Will
fight with it some other time.

Or, maybe, it is time to pitch Windows and switch to another OS? This really
sucks. Third month in a row that Windows Update has caused problems
requiring manually deleting system files, and manually downloading the
patching .exe files.

--
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.

 

[Alias]

N. Miller wrote:

> Or, maybe, it is time to pitch Windows and switch to another OS?

Check out Ubuntu at www.ubuntu.com It's free and comes with access to
over 24,000 free programs.

Alias

 

[Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]]

Interesting as I've never had that MSRT cause any issues and never
wanted a restart. Can you post the log up here?

N. Miller wrote:
> I have spent almost as much time troubleshooting a failure to run of the
> Malicious Software Removal Tool on two computers, as it would have taken to
> "scrape and build".
>
> Case A: HP Pavilion m7590n. Originally shipped with Windows MCE 2005 SP2
> upgraded to SP3. MSRT for August 2008 triggers a system restart, and all
> updates failed. I finally ran "Custom", and installed each of 9 updates one
> by stinking one. When I hit KB890830, as the installation progress bar was
> marching across the screen, there was a very audible "click", as something
> tripped the P.S., and system shut down, and restarted. Went into file system
> check mode, and came back still wanting to run the MSRT.
>
> Case B: HP Pavilion 6745C. Originally shipped with Windows Me, obtained a
> Windows XP Home Edition SP2 upgrade pack from Fry's Electronics, and did a
> clean install on NTFS partitions. Added SP3 before setting up the
> applications. I let it run with 13 "Critical Updates" to work on, came back
> to find it had rebooted spontaneously. Went back to the Windows Update site
> only four of the updates had installed. Went to "Custom" mode, and installed
> all but KB890830. Installation was normal. However, as with Case A:,
> KB890830 triggers a shutdown before it has begun to run. At this time, MSRT
> has not been run on the Pavilion 6745C. I can't force it into Safe Mode the
> same way as with the Pavilion m7590n F8 key. Too tired to continue at this
> time been 12 hours since I began screwing around with this issue. Will
> fight with it some other time.
>
> Or, maybe, it is time to pitch Windows and switch to another OS? This really
> sucks. Third month in a row that Windows Update has caused problems
> requiring manually deleting system files, and manually downloading the
> patching .exe files.
>

 

[PA Bear [MS MVP]]

Unexplained computer behavior may be caused by deceptive software
http://support.microsoft.com/kb/827315

Run a /thorough/ check for hijackware, including posting your hijackthis log
to an appropriate forum.

Checking for/Help with Hijackware
http://aumha.org/a/parasite.htm
http://aumha.org/a/quickfix.htm
http://aumha.net/viewtopic.php?t=5878
http://wiki.castlecops.com/Malware_Removal_and_Prevention:_Introduction
http://mvps.org/winhelp2002/unwanted.htm
http://inetexplorer.mvps.org/data/prevention.htm
http://inetexplorer.mvps.org/tshoot.html
http://www.mvps.org/sramesh2k/Malware_Defence.htm
http://defendingyourmachine2.blogspot.com/
http://www.elephantboycomputers.com/page2.html#Removing_Malware

When all else fails, HijackThis v2.0.2
(http://aumha.org/downloads/hijackthis.exe) is the preferred tool to use (in
conjuction with some other utilities). HijackThis will NOT fix anything on
its own, but it will help you to both identify and remove any
hijackware/spyware with assistance from an expert. **Post your log to
http://aumha.net/viewforum.php?f=30,
http://forums.spybot.info/forumdisplay.php?f=22,
http://castlecops.com/forum67.html, or other appropriate forums for review
by an expert in such matters, not here.**

If the procedures look too complex - and there is no shame in admitting this
isn't your cup of tea - take the machine to a local, reputable and
independent (i.e., not BigBoxStoreUSA or Geek Squad) computer repair shop.
--
~Robear Dyer (PA Bear)
MS MVP-IE, Mail, Security, Windows Desktop Experience - since 2002
AumHa VSOP & Admin http://aumha.net
DTS-L http://dts-l.net/

N. Miller wrote:
> I have spent almost as much time troubleshooting a failure to run of the
> Malicious Software Removal Tool on two computers, as it would have taken
> to
> "scrape and build".
>
> Case A: HP Pavilion m7590n. Originally shipped with Windows MCE 2005 SP2
> upgraded to SP3. MSRT for August 2008 triggers a system restart, and all
> updates failed. I finally ran "Custom", and installed each of 9 updates
> one
> by stinking one. When I hit KB890830, as the installation progress bar was
> marching across the screen, there was a very audible "click", as something
> tripped the P.S., and system shut down, and restarted. Went into file
> system
> check mode, and came back still wanting to run the MSRT.
>
> Case B: HP Pavilion 6745C. Originally shipped with Windows Me, obtained a
> Windows XP Home Edition SP2 upgrade pack from Fry's Electronics, and did a
> clean install on NTFS partitions. Added SP3 before setting up the
> applications. I let it run with 13 "Critical Updates" to work on, came
> back
> to find it had rebooted spontaneously. Went back to the Windows Update
> site
> only four of the updates had installed. Went to "Custom" mode, and
> installed
> all but KB890830. Installation was normal. However, as with Case A:,
> KB890830 triggers a shutdown before it has begun to run. At this time,
> MSRT
> has not been run on the Pavilion 6745C. I can't force it into Safe Mode
> the
> same way as with the Pavilion m7590n F8 key. Too tired to continue at
> this
> time been 12 hours since I began screwing around with this issue. Will
> fight with it some other time.
>
> Or, maybe, it is time to pitch Windows and switch to another OS? This
> really
> sucks. Third month in a row that Windows Update has caused problems
> requiring manually deleting system files, and manually downloading the
> patching .exe files.

 

[N. Miller]

On Wed, 13 Aug 2008 10:44:47 -0400, PA Bear [MS MVP] wrote:

> Unexplained computer behavior may be caused by deceptive software...

This KB890830 is the *only* "unexplained" behavior. First showed up on a
computer on which I had recently installed the "TVeristy" media server, and
upgraded from 2 GB to 4GB of RAM. First thing I did was run Avas scan, then
downloaded, and ran, the MSFT memory diagnostic tool. Avast reports no
malware (dicounting a half dozen false positives I *know* what those
applications that Avast was alerting on do! Including the iTunes uninstaller
application!). The MSFT memory diagnostic looped four times without error.

--
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.

 

[N. Miller]

On Wed, 13 Aug 2008 07:08:54 -0700, Susan Bradley, CPA aka Ebitz - SBS Rocks
[MVP] wrote:

> Interesting as I've never had that MSRT cause any issues and never
> wanted a restart. Can you post the log up here?

I tried posting the log as an attached .zip file. Client says it went out,
but the file is 61 kBytes.

--
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.

 

[Harry Johnston [MVP]]

N. Miller wrote:

> [...] Avast reports no
> malware (dicounting a half dozen false positives

That sounds unlikely. What applications are these?

> I *know* what those
> applications that Avast was alerting on do! Including the iTunes uninstaller
> application!).

But do you know whether your copy of the application has been modified to
contain malware?

Harry.

--
Boycott Beijing 2008 http://www.rsf.org/rubrique.php3?id_rubrique=174

 

[N. Miller]

On Fri, 15 Aug 2008 10:36:00 +1200, Harry Johnston [MVP] wrote:

> N. Miller wrote:

>> [...] Avast reports no
>> malware (dicounting a half dozen false positives

> That sounds unlikely. What applications are these?

C:\Program Files\iTunes\Plug-ins\amip_uninstall.exe
C:\Program Files\Online
Service\PeoplePC\ISP5900\Branding\ppal3ppc.exe\$INSTDIR\PPCToolbar.dll
C:\Program Files\Passware\ariskkey.dll
C:\System Volume Information\_restore....(I believe this one is one of the
EICAR files the log line runs on beyond the number of supported
characters). EICAR is *not* malicious, but always detected.
C:\Programs\music_now\inetchk.exe

"AMIP" is a WinAmp plugin for iTunes. The file creation date is consistent
with the file creation dates for the Wimamp install folder. Because of the
fact that I was typing while the scan was running, I managed to blow away
the uninstaller for this plug-in.

"ppal3ppc.exe" is an OEM included installer for the PeoplePC Internet
service.

"Passware" is a password reveler which I installed. AV programs are noted
for alerting on applications which are *potentially* malicious, leaving it
up to the operator to know, for sure, whether they installed such software,
or not.

EICAR is, well, EICAR. http://en.wikipedia.org/wiki/Eicar_test_file

"Inetchk.exe" is in another of the OEM included files, this one pertaining
to AOL's "Music Now".
http://www.timewarner.com/corp/newsroom/pr/0,20812,1448986,00.html

> But do you know whether your copy of the application has been modified to
> contain malware?

They are in the proper folders, as originally installed, and have file
creation dates consistent with the other files in those folders.

HJT log shows nothing malicious. AdAware and Spybot S&D show nothing
malicious.

CurrPorts shows no suspicious connections, or applications listening. If
there is anything malicious on this box, it is very well hidden. I have not
run a rootkit scan. Primarily because, aside from the MSRT dumping the power
during its run, nothing unexplained is going on.

Oh, and finding an MVP who posted a suggestion to another user with a
similar problem seems to indicate an MSRT problem. The solution offered was
to download the latest version of KB890830, go to %Windows$\System32, delete
the 'msrt.exe' file, reboot to "Safe Mode", and run the newly downloaded
file. When I did that, MSRT ran normally, *without* dumping the power.

--
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.

 

[Harry Johnston [MVP]]

N. Miller wrote:

> "AMIP" is a WinAmp plugin for iTunes. The file creation date is consistent
> with the file creation dates for the Wimamp install folder.

I'm sure most viruses nowadays make sure the file creation/modification date
doesn't change when they infect a file. If this is really a legitimate piece of
code, it seems unlikely that Avast would flag it - though it would be worth
checking with the WinAmp folks.

> "Passware" is a password reveler which I installed.

OK, that one is probably a genuine false positive.

> EICAR is, well, EICAR. http://en.wikipedia.org/wiki/Eicar_test_file

Not *exactly* a false positive, but not a risk either.

> Oh, and finding an MVP who posted a suggestion to another user with a
> similar problem seems to indicate an MSRT problem. The solution offered was
> to download the latest version of KB890830, go to %Windows$\System32, delete
> the 'msrt.exe' file, reboot to "Safe Mode", and run the newly downloaded
> file. When I did that, MSRT ran normally, *without* dumping the power.

OK thanks for letting us know. It's very odd, though MSRT is user-mode code,
meaning it shouldn't be able to crash the computer even if it is faulty. Also I
wasn't aware that MSRT put a file in system32 in the first place. Certainly
there's no such file on my system, even when MSRT is actually running.

Harry.

--
Boycott Beijing 2008 http://www.rsf.org/rubrique.php3?id_rubrique=174

 

[MowGreen [MVP]]

http://support.microsoft.com/kb/890830

" How to remove the Malicious Software Removal Tool
The Malicious Software Removal Tool does not use an installer.
Typically, when you run the Malicious Software Removal Tool, it creates
a randomly named temporary directory on the root drive of the computer.
This directory contains several files, and it includes the Mrtstub.exe
file. Most of the time, this folder is automatically deleted after the
tool finishes running or after the next time that you start the
computer. However, this folder may not always be automatically deleted.
In these cases, you can manually delete this folder, and this has no
adverse effect on the computer. "

It's present on my XP Pro system in sys32.
What happens if you run mrt from the Run line ?


MowGreen [MVP 2003-2008]
===============
*-343-* FDNY
Never Forgotten
===============



Harry Johnston [MVP] wrote:

> N. Miller wrote:
>
>> "AMIP" is a WinAmp plugin for iTunes. The file creation date is
>> consistent
>> with the file creation dates for the Wimamp install folder.
>
>
> I'm sure most viruses nowadays make sure the file creation/modification
> date doesn't change when they infect a file. If this is really a
> legitimate piece of code, it seems unlikely that Avast would flag it -
> though it would be worth checking with the WinAmp folks.
>
>> "Passware" is a password reveler which I installed.
>
>
> OK, that one is probably a genuine false positive.
>
>> EICAR is, well, EICAR. http://en.wikipedia.org/wiki/Eicar_test_file
>
>
> Not *exactly* a false positive, but not a risk either.
>
>> Oh, and finding an MVP who posted a suggestion to another user with a
>> similar problem seems to indicate an MSRT problem. The solution
>> offered was
>> to download the latest version of KB890830, go to %Windows$\System32,
>> delete
>> the 'msrt.exe' file, reboot to "Safe Mode", and run the newly downloaded
>> file. When I did that, MSRT ran normally, *without* dumping the power.
>
>
> OK thanks for letting us know. It's very odd, though MSRT is
> user-mode code, meaning it shouldn't be able to crash the computer even
> if it is faulty. Also I wasn't aware that MSRT put a file in system32
> in the first place. Certainly there's no such file on my system, even
> when MSRT is actually running.
>
> Harry.
>

 

[N. Miller]

On Fri, 15 Aug 2008 13:58:13 +1200, Harry Johnston [MVP] wrote:

> N. Miller wrote:

>> "AMIP" is a WinAmp plugin for iTunes. The file creation date is consistent
>> with the file creation dates for the Wimamp install folder.

> I'm sure most viruses nowadays make sure the file creation/modification date
> doesn't change when they infect a file. If this is really a legitimate piece of
> code, it seems unlikely that Avast would flag it - though it would be worth
> checking with the WinAmp folks.

I suspect that it would be a strange bit of malware to *only* infect an
uninstaller program for a single application. The malware wouldn't have a
chance to run unless the victim decided to uninstall the application. Could
be a long time to forever, depending upon the application. Were I writing an
infection, I'd want to multiply my chances of getting the malware started
I'd infect multiple main app files across the HDD to maximize the chance of
my malware being executed.

> OK thanks for letting us know. It's very odd, though MSRT is user-mode code,
> meaning it shouldn't be able to crash the computer even if it is faulty. Also I
> wasn't aware that MSRT put a file in system32 in the first place. Certainly
> there's no such file on my system, even when MSRT is actually running.

Sorry, it was 'mrt.exe':

http://forums.techarena.in/windows-update/659335.htm

MowGreen [MVp 2003-2007], #4.

--
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.

 

[N. Miller]

On Wed, 13 Aug 2008 07:08:54 -0700, Susan Bradley, CPA aka Ebitz - SBS Rocks
[MVP] wrote:

> Interesting as I've never had that MSRT cause any issues and never
> wanted a restart. Can you post the log up here?

I have tried posting the log. Twice. Not sure what the Microsoft NNTP
servers will accept, but my posts aren't making it through.

Here is something interesting: After the July Windows Updates ran, I
installed a Netgear SC-101 NAS (Network Attached Storage) device. Installed
software for it on three computers. I haven't examined the third one
closely, but it had a mysterious "serious error" report, similar to the one
on my HP Pavilion m7590n. The three computers are:

HP Pavilion m7590n, Windows MCE 2005, SP3
HP Pavilion a1440n, Windows MCE 2005, SP3
HP Pavilion 6745C, Windows XP HE, SP3

In common they have installed the "Netger Storage Central Manager Utility".

While updated some media files on the L: drive on the Pavilion m7590n, I
noticed some odd folders:

1f35316d14e6aebb8a22aafd2733783d {Created: Aug. 12, 2008, 21:59:27}
0021ee6e3a835c2662 {Created: Aug. 12, 2008, 14:26:59}
4589a0c2a93a16d5f294e7f4bc87 {Created: Aug. 13, 2008, 04:29:20}
416539e6229e527422c5 {Created: Aug. 12, 2008, 15:23:53}
b882f7407bafe0ef0d {Created: Aug. 12, 2008, 14:17:46}
b5076e7fb2e00705fd75f1c45f21 {Created: Aug. 12, 2008, 15:09:57}
dfc28be7ed3a972519f502fdeddc8d45 {Created: Aug. 12, 2008, 21:40:19}

The file creation dates and times are consistent with my attempts at getting
the computers updated. I especially recognize the Aug. 13, 2008 date/time
that was when I gave up on the HP Pavilion 6745C for being unable to get it
to boot to Safe Mode!

All folders have the same three files in them:

$shtdwn$.req
mrt.exe._p
mrtstub.exe

The first file seems to belie the "Never wanted a restart comment". It looks
suspiciously like an abbreviation for: "Shutdown required"!

My question is: Why would these files be written to the last disk volume
letter which is not a mapped network drive? This NAS drive (different letter
on each of the three computers) is dependent on the Netgear NAS manager
loading, and I would guess it hasn't yet loaded right after a forced
restart, so the Malicious Software Removal Tool fails for lack of finding
the necessary files after a restart.

--
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.

 

[N. Miller]

On Fri, 15 Aug 2008 13:58:13 +1200, Harry Johnston [MVP] wrote:

>> Oh, and finding an MVP who posted a suggestion to another user with a
>> similar problem seems to indicate an MSRT problem. The solution offered was
>> to download the latest version of KB890830, go to %Windows$\System32, delete
>> the 'msrt.exe' file, reboot to "Safe Mode", and run the newly downloaded
>> file. When I did that, MSRT ran normally, *without* dumping the power.

> OK thanks for letting us know. It's very odd, though MSRT is user-mode code,
> meaning it shouldn't be able to crash the computer even if it is faulty. Also I
> wasn't aware that MSRT put a file in system32 in the first place. Certainly
> there's no such file on my system, even when MSRT is actually running.

I am not sure what trips the power supply, but something does it. What I
have discovered is that some temp files were written to the NAS "L:\"
volume, and when the power was dumped, and restarted, and because the NAS
"Storage Central Manager" utility had not, yet, booted, WUPDATE looked for
its temp files on the last HDD volume it could find. Of course, those files
weren't there, triggering a "file system integrity check" on the boot, and
then a "Windows has encountered a serious problem" warning, with an option
to send a report to Microsoft. And the pending updates still flagged as
needing installation. A couple of cycles of that with each of three
machines, and I had a dozen temp folders on the NAS volume!

Thinking that WUPDATE was writing to the last volume in the list, I
re-ordered the volume labels. But now I am reading that WUPDATE is writing
the temp files to the volume with the most free space. This will still be
the NAS, at the present time, no matter where I order it. This appears to be
a logical flaw in the way that WUPDATE is designed. I guess I will have to
change my WUPDATE option away from "Automatic", to "Notification" only, so I
can kill power to the NAS *before* I let WUPDATE do its work.

--
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.

 

[Stefan Kanthak]

"N. Miller" <anonymous@msnews.aosake.net> wrote:

> On Fri, 15 Aug 2008 13:58:13 +1200, Harry Johnston [MVP] wrote:
>
>>> Oh, and finding an MVP who posted a suggestion to another user with a
>>> similar problem seems to indicate an MSRT problem. The solution offered was
>>> to download the latest version of KB890830, go to %Windows$\System32, delete
>>> the 'msrt.exe' file, reboot to "Safe Mode", and run the newly downloaded
>>> file. When I did that, MSRT ran normally, *without* dumping the power.
>
>> OK thanks for letting us know. It's very odd, though MSRT is user-mode code,
>> meaning it shouldn't be able to crash the computer even if it is faulty. Also I
>> wasn't aware that MSRT put a file in system32 in the first place. Certainly
>> there's no such file on my system, even when MSRT is actually running.
>
> I am not sure what trips the power supply, but something does it.

Why do you think MSRT.EXE is the culprit?
This program runs in user mode and scans your disk using normal IO.
It very much looks as if due to this scan either an error in your
harddisk/hardware is triggered (I have two PATA disks here which
have "bad spots" which trigger a hardware reset when scanned too)
or a software error which does not yield a BSOD but an immediate
reboot (yes, those do happen).

> What I
> have discovered is that some temp files were written to the NAS "L:\"
> volume,

You have been told that the selfextractor code of patches/hotfixes
selects the partition with the most free space to unpack itself!

> and when the power was dumped, and restarted, and because the NAS
> "Storage Central Manager" utility had not, yet, booted, WUPDATE looked for
> its temp files on the last HDD volume it could find.

That's wrong too!
The files unpacked by the selfextractor are ALL "consumed" during the
install and copied to their target directories BEFORE the patch/hotfix
installer returns to its caller.
If you choose NOT to reboot during the hotfix install all the temporary
files and the directory are removed, but if you choose to reboot at
least the @:\<gibberish>\UPDATE\UPDATE.EXE and the two directories
remain.... until after the reboot: their names are written to the
"PendingFileRenameOperations" registry key and schedule for deletion
upon reboot. Now if your disk happens not to be accessible during
reboot this delete operation silently fails.
This mechanism is used with Windows NT for almost 15 years now!

> Of course, those files
> weren't there, triggering a "file system integrity check" on the boot,

Now that's complete nonsense!
A "file system integrity check" a.k.a. CHKDSK run is only triggered when
the filesystem meta data are SERIOUSLY corrupted. A missing file but is
NO such problem!

> and then a "Windows has encountered a serious problem" warning,

Which almost always indicates a hardware problem. I bet Windows sees
some kind of data corruption, either in filesystem meta data or some
executables, due to that hardware error, which is also triggered by
the MSRT.EXE run.
Get another on-demand virus scanner (for example TrendMicro's free
"System Cleaner" <http://www.trendmicro.com/download/sysclean.asp>)
and let it scan your system: expect the same failure as triggered by
MSRT.EXE.

> with an option
> to send a report to Microsoft. And the pending updates still flagged as
> needing installation.

That's strange ... and looks as if the "PendingFileRenameOperations"
which are also used to replace system files in use are failing completely
so that the next scan for missing updates detects the same old files to
be updated again and again.

Take a THOROUGH look into the KBxxxxxx.log files in your Windows
directory, especially where all the file versions and the pending file
rename operations are listed.

> A couple of cycles of that with each of three
> machines, and I had a dozen temp folders on the NAS volume!

Unfortunately "normal" behaviour.

Stefan

 

[N. Miller]

On Sat, 23 Aug 2008 21:22:25 +0200, Stefan Kanthak wrote:

> Why do you think MSRT.EXE is the culprit?

I think Windows Update is the culprit. The only "virus" on that system is
the Netgear "Storage Central Management" utility, which makes the NAS volume
available to the system. The only time I encounter errors is when Windows
Update runs concurrent with the NAS device.

The only trick I know, at this time, to get around this issue is to turn off
WUPDATE Autoinstall and Autodownload. I can configure it to just notify me
when updates are available. Give me time to disable the NAS first, then go
to the WUPDATE site and manually run the updates. Royal PITA, but it will
work.

--
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.

 

[Stefan Kanthak]

"N. Miller" <anonymous@msnews.aosake.net> wrote:

> On Sat, 23 Aug 2008 21:22:25 +0200, Stefan Kanthak wrote:
>
>> Why do you think MSRT.EXE is the culprit?
>
> I think Windows Update is the culprit.

Go read my post again, then TRY to understand!

> The only "virus" on that system is
> the Netgear "Storage Central Management" utility, which makes the NAS volume
> available to the system. The only time I encounter errors is when Windows
> Update runs concurrent with the NAS device.

Then draw the apparent conclusion: this Netgear software is the culprit!
Does Netgear declare their device and software "compatible with Windows"?
If yes: go ask them why their device and software break a basic function
of Windows available and turned on since at least 6 years!
Ask them whether and how they tested their device and software for
compatibility, especially with the builtin "automatic updates".

But: what causes the system reboot/reset you mention.

BTW: (access to) a NAS does NOT depend on a "storage central management"
to be run on a client. Your so-called NAS is apparently some weird device!
A real/classic NAS typically exports its filesystem via NFS, CIFS or some
other widespread protocol native spoken by its clients.
A real/classic SAN typically exports its devices and may need some block
device driver (or a "standard" HBA) to import these devices as typically
so called LUNs into the block device management of the clients.

Stefan

 

[Robert Aldwinckle]

"N. Miller" <anonymous@msnews.aosake.net> wrote in message
news:1kgzjbpybvl3n.dlg@msnews.aosake.net...
> On Wed, 13 Aug 2008 07:08:54 -0700, Susan Bradley, CPA aka Ebitz - SBS Rocks
> [MVP] wrote:
>
>> Interesting as I've never had that MSRT cause any issues and never
>> wanted a restart. Can you post the log up here?
>
> I have tried posting the log. Twice. Not sure what the Microsoft NNTP
> servers will accept, but my posts aren't making it through.


Perhaps more to the point of this suggestion, do the mrt.log have anything
"interesting" in them at the bottom? If so, you could post the last few uses
of it. E.g. the mrt.log is a cumulative log... )

Hmm... I just noticed that even though I have always been getting "No infection found.",
there are occasional hiccups caused it seems by various drivers. Unfortunately the log
doesn't give any clues about how severe those impediments may have been
for the scan's execution. If they happened repeatedly and I suspected that they
would happen again I would try running ProcMon to hope for more clues.
E.g. at the very least it would give an accurate timestamp for each record written
to the mrt.log and possibly show some "interesting" file and registry accesses
in between them. )


---


>
> Here is something interesting: After the July Windows Updates ran, I
> installed a Netgear SC-101 NAS (Network Attached Storage) device. Installed
> software for it on three computers. I haven't examined the third one
> closely, but it had a mysterious "serious error" report, similar to the one
> on my HP Pavilion m7590n. The three computers are:
>
> HP Pavilion m7590n, Windows MCE 2005, SP3
> HP Pavilion a1440n, Windows MCE 2005, SP3
> HP Pavilion 6745C, Windows XP HE, SP3
>
> In common they have installed the "Netger Storage Central Manager Utility".
....

 

[N. Miller]

On Wed, 27 Aug 2008 22:32:29 -0400, Robert Aldwinckle wrote:

> "N. Miller" <anonymous@msnews.aosake.net> wrote in message
> news:1kgzjbpybvl3n.dlg@msnews.aosake.net...

>> On Wed, 13 Aug 2008 07:08:54 -0700, Susan Bradley, CPA aka Ebitz - SBS Rocks
>> [MVP] wrote:

>>> Interesting as I've never had that MSRT cause any issues and never
>>> wanted a restart. Can you post the log up here?

>> I have tried posting the log. Twice. Not sure what the Microsoft NNTP
>> servers will accept, but my posts aren't making it through.

> Perhaps more to the point of this suggestion, do the mrt.log have anything
> "interesting" in them at the bottom? If so, you could post the last few uses
> of it. E.g. the mrt.log is a cumulative log... )

Here is the tail end of the log, since last July:

| Microsoft Windows Malicious Software Removal Tool v2.0, July 2008
| Started On Wed Jul 09 00:12:17 2008
| ->Scan ERROR: resource process://pid:5948 (code 0x00000057 (87))
| ->Scan ERROR: resource process://pid:5948 (code 0x0000054F (1359))
|
| Results Summary:
| ----------------
| No infection found.
|
| Return code: 0
| Microsoft Windows Malicious Software Removal Tool Finished On Wed Jul 09 00:14:33 2008
|
|
| ---------------------------------------------------------------------------------------
|
| Microsoft Windows Malicious Software Removal Tool v2.1, August 2008
| Started On Tue Aug 12 21:26:21 2008
|
| Results Summary:
| ----------------
| No infection found.
|
| Return code: 0
| Microsoft Windows Malicious Software Removal Tool Finished On Tue Aug 12 21:28:45 2008

The 'mrt.exe' update dumps the power supply when downloaded to the desktop
and run. Leaves a temp file on the NAS.

> Hmm... I just noticed that even though I have always been getting "No infection found.",
> there are occasional hiccups caused it seems by various drivers. Unfortunately the log
> doesn't give any clues about how severe those impediments may have been
> for the scan's execution. If they happened repeatedly and I suspected that they
> would happen again I would try running ProcMon to hope for more clues.
> E.g. at the very least it would give an accurate timestamp for each record written
> to the mrt.log and possibly show some "interesting" file and registry accesses
> in between them. )

Ran fine on one of three computers. I had started moving files to the NAS.
Current state of affairs:

Machine A:
==========
Local HD (C: 127GB free
Local HD (D: 124GB free
NAS: 203GB free

Machine B:
Local HD (C: 130GB free
Local HD (D: 209GB free
NAS: 203GB free

Machine C:
Local HD (C: 8GB free
Local HD (D: 100MB free
Local HD (E: 180MB free
Local HD (F: 22GB free
NAS: 203GB free

Only on Machine B does 'mrt.exe' run without dumping the power supply. NAS
access is controlled by 'Z-SANService.exe', running under user "SYSTEM" as a
process (as listed by Windows Task Manager on Machine A).

Event Viewer shows a couple of application errors at 2:41:12, or so.

--
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.