Text 635, 80 rader
Skriven 2007-03-26 08:43:32 av Mike Luther (1:117/3001.0)
Ärende: What is NSRWS.EXE?
==========================
Subject says about the whole question. but ..

I have odd lockups on one box which after it happens always leave a cleanup
issue that UNIMAINT finds.  UNIMAINT finds that the program NSRWS.EXE is
missing from  \TEMP for the system.  But try as I might,there is no
'conventional' such file NSRWS.EXE anywhere on the system!

I suspected something related to Norman's virus product which is on the box
with the hard lockup issue.  Until I saw this in UNIMAINT on two other boxes
which didn't have 5.8.  I next suspected that Privoxy was at issue in the
lockups, which at that point were Red Light district hard locks.  However, I'm
now pretty convinced that Privoxy is only a complication for the Red Light
District with it's log file constantly open and the cache idle bitty-bit
ascending snippet log in the slush pit.  I got rid of it in STARTUP and open it
with use of Seamonkey, then shut it down.  No more Red Light district ventures
- instead when the box locks there is no file activity I can detect. 
 Far fewer .INI file contamination issues after punch button restart as well.

The curious part about this one is that I've seen this strange NSRWS.EXE into
an .INI file taint issue surface even if the box is totally unattended for a
few days, doing logging of serial port and phone line activity only.  And I
thought about SIO2K questions and time slice tools in use here, but when this
curious item showed up in a box with SIO and no DOS-VDM sessions left running,
I've shuffled this pig trail aside.

Prior to cleanout of the NSRWS.EXE taint with UNIMAINT, I've looked at these
boxes with THESEUS trying to find a process which might have something to do
with this.  Not that I can find.  The lockup prone box is actually connected to
the Internet behind the Injoy firewall.  And all of this is behind a ZyXel
router with more firewall isolation, even for the other boxes which have shown
it.  None of these boxes are Netbios Over TCP/IP enabled - I learned that
lesson a long time ago.

I don't leave any box up against the LAN when not using the LAN.  Thus I see
this one even when no server-client relationship is in use and I can confirm
from watching this over a long time that it can take place even though a box
has never been used for LAN connectivity.  Although the lockup prone box is
used for PEER service.

This issue seems pointed toward appearing when .INI file updates might be
involved, but then .. if a couple days have gone by with no activity other than
comm port I/O and phone line logging is being done, that sort of discourages
those thoughts.  As well, I've even gone through and cleaned up the .INI files
with CHECKINI from the WPT set as well.  And looking through the .INI files
with UNIMAINT doesn't show this as a cited item when we start out with a clean
file.  And with no human access to the affected box go away for a couple days
and POOF it is there!

I've looked through all my .BAT and .CMD files - no item like it.  I've come
back from the day or so non-contact and looked at the socket connections with
NETSTAT.  Nothing noted unusual -- and there will be the UNIMAINT find of the
.INI file NSRWS.EXE item!

Once getting rid of the Red Light District hard locks by taking Privoxy off
line, I now can at times see a parade of SYS3* errors, which if I rapidly hit
<CTRL ALT DEL> a couple of times, I can force a reboot that will bring the box
back up.  This if I leave the NSRWS.EXE item in there just for test.  And the
parade of SYS3* errors beep - beep - beep will be a series of PMSHELL traps,
including PMMERGE.DLL and DOSCALL1.DLL.

Is this the curious glitch that really is involved in the PMSHELL failures for
XRC005 that some have seen and I am just now noticing and thought I didn't
have?  This strange NSRWS.EXE deal is the real 'cause' of the PMSHELL errors
that affect some, but not others with XRC005?

Does ANYONE here know anything about this NSRWS.EXE item and what it is all
about?  I can't even find a .DLL anywhere with that name which might be in
error thought to be an .EXE in the \TEMP file.  I can't even find any reference
to it at all with a GOOGLE search!  And no answer in the OS/2 Internet forums
either.

Help?


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)