|
Posted by =?Utf-8?B?T2xkUmViZWwy?= on February 26, 2007, 6:35 pm
If you were Registered and logged in, you could reply and use other advanced thread options
I realized that when I saw the changes in the new version. Thanks. My dilema
is that I have this pesky problem that keeps reoccurring in different
"incarnations" of Windows. Everytime I think I have found a cause, or a
possible solutions, it slips me grasp. To date, recovery has always involved
reformatting, but I suspect there's another solution somewhere. I just don't
know where.
--
Regards,
Paul B. aka "OldRebel"
"David H. Lipman" wrote:
>
> | Thank you again for your replies. I don't want you to think that I don't
> | appreciate the tool. I have had this Welcome Screen problem occur several
> | times in the past, and have never figured out why. I used to think that
> | Windows Defender or One Care caused it, but apparently not, becuase I have
> | neither at this time. The only common factor *that I can think of* is using
> | Multi_AV, but that doesn't rule out another *unknown* issue. I'll keep
> | looking.
>
> I KNOW you appreciate the tool. It was based upon YOURS and other feedback
that I applied
> to the last update.
>
> I'm trying to be as helpful and responsive as possible.
>
> --
> Dave
> http://www.claymania.com/removal-trojan-adware.html
> http://www.ik-cs.com/got-a-virus.htm
>
>
>
|
|
Posted by cquirke (MVP Windows shell/use on March 3, 2007, 2:37 am
If you were Registered and logged in, you could reply and use other advanced thread options
On Sun, 25 Feb 2007 20:43:31 -0500, "David H. Lipman"
>| Yes. None of them found anything and none did anything. I had selected the
>| choice to detect only. I think it happened before I even ran the scans.
Did you suffer bad exits before doing the scans?
What circumstances prompted you to suspect malware?
Was any malware found or reported by anything else (other than MAV)?
>| Multi_AV is doing things behind the scenes when you first execute it: like
>| giving WGET.EXE Windows Firewall exception (as well as needing permission
>| from any 3rd party firewall). There's also some explanation in the help file
>| that it changes some configuration file to a .bak file, but I don't
>| understand all of that. Somehow, I just intuit that it is a goup policy or
>| permissions problem, but I am not techincal enough to figure it out.
TweakUI for XP gives some control over the "Welcome" (pre-login)
environment; there may be something there about hiding or presenting
the option to shut down from there.
On a modern PC, briefly pressing the ATX "off" button should issue the
OS an instruction to shut down, rather than simply switch "off".
>The Multi AV Scanning Tool menu will do some anti malware measures...
>
>- Backup the etc/hosts file and remove it
That implies any protective HOSTS routing (e.g. deliberately routing
known-bad domains to 0.0.0..0 or 127.0.0.1) will be lost.
>- Atrempt to allow WGET.EXE access through the WinXP FireWall
>- Restore the default; AUTOEXEC.NT and CONFIG.NT after backing them up.
>- Remove local and systempolicies that limit the use of the PC.
Hmm... OK
>- Fix file associations corrupted by malware ["batfile", "comfile", "exefile",
"regfile",
>"scrfile" and "piffile"]
cmdfile?
>There is nothing in the MENU.KIX file that disable or remove a button to "turn
off
>computer".
OK.
It also may close web browsers when it runs?
It would be nice to checkbox these changes for interactive user
(de)selection, so the user's more aware (and in control) of what is
being done. Then again, that may be hard to UI in Kix
>If it isn't malware then there some "other" cause. Since I have not examined
this concept I
>don't know what can cause it.
>I can emphatically state that I know what every line of code and function WILL
do.
I've not seen issues with the Welcome screen's shutdown item either,
but I have seen stuff on malware involving itself at this level
(MSGINA or similar subsystems affected, as well as Winlogin).
>--------------- ---- --- -- - - - -
Saws are too hard to use.
Be easier to use!
>--------------- ---- --- -- - - - -
|
|
Posted by David H. Lipman on March 3, 2007, 8:00 am
If you were Registered and logged in, you could reply and use other advanced thread options
| On Sun, 25 Feb 2007 20:43:31 -0500, "David H. Lipman"
>>| Yes. None of them found anything and none did anything. I had selected the
>>| choice to detect only. I think it happened before I even ran the scans.
| Did you suffer bad exits before doing the scans?
| What circumstances prompted you to suspect malware?
| Was any malware found or reported by anything else (other than MAV)?
>>| Multi_AV is doing things behind the scenes when you first execute it: like
>>| giving WGET.EXE Windows Firewall exception (as well as needing permission
>>| from any 3rd party firewall). There's also some explanation in the help file
>>| that it changes some configuration file to a .bak file, but I don't
>>| understand all of that. Somehow, I just intuit that it is a goup policy or
>>| permissions problem, but I am not techincal enough to figure it out.
| TweakUI for XP gives some control over the "Welcome" (pre-login)
| environment; there may be something there about hiding or presenting
| the option to shut down from there.
| On a modern PC, briefly pressing the ATX "off" button should issue the
| OS an instruction to shut down, rather than simply switch "off".
>>The Multi AV Scanning Tool menu will do some anti malware measures...
>>- Backup the etc/hosts file and remove it
| That implies any protective HOSTS routing (e.g. deliberately routing
| known-bad domains to 0.0.0..0 or 127.0.0.1) will be lost.
>>- Atrempt to allow WGET.EXE access through the WinXP FireWall
>>- Restore the default; AUTOEXEC.NT and CONFIG.NT after backing them up.
>>- Remove local and systempolicies that limit the use of the PC.
| Hmm... OK
>>- Fix file associations corrupted by malware ["batfile", "comfile", "exefile",
>>"regfile",
>>"scrfile" and "piffile"]
| cmdfile?
>>There is nothing in the MENU.KIX file that disable or remove a button to "turn
off
>>computer".
| OK.
| It also may close web browsers when it runs?
It will Kill the processes of; Firefox, IE and Opera by design to keep them
from holding
malware file handles open as well as any malware that may bu using their names.
It is
ALWAYS a good idea to close ALL programs prior to performing an On Demand scan
and so this
measure makes sure these are auto-closed.
| It would be nice to checkbox these changes for interactive user
| (de)selection, so the
| user's more aware (and in control) of what is
| being done. Then again, that may be hard
| to UI in Kix
Those options can be toggled on/off but it is meant to be simple and not
compliacted with
lots of various operting parameters. I see no reason for them to be disabled
anyway. As
I wrote one should always close ALL programs before performing an On Demand scan
in the
first place.
If I was to include such a capability I could create an INI file that can have
the
prarameters set to YES or NO so it can be easily programmed and easily
manipulated by the
End User. Such an INI file could be edited from within the Menu.
>>If it isn't malware then there some "other" cause. Since I have not
| examined this
>>concept I
>>don't know what can cause it.
>>I can emphatically state that I
| know what every line of code and function WILL do.
| I've not seen issues with the
| Welcome screen's shutdown item either,
| but I have seen stuff on malware involving
| itself at this level
| (MSGINA or similar subsystems affected, as well as
| Winlogin).
>>--------------- ---- --- -- - - - -
| Saws are too hard to
| use.
| Be easier to use!
>>--------------- ---- --- -- - - - -
-- -- - - - -
--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm
|
|
Posted by cquirke (MVP Windows shell/use on March 11, 2007, 9:16 am
If you were Registered and logged in, you could reply and use other advanced thread options
>From: "cquirke (MVP Windows shell/user)"
>| It also may close web browsers when it runs?
>It will Kill the processes of; Firefox, IE and Opera by design to keep them
from holding
>malware file handles open as well as any malware that may bu using their names.
It is
>ALWAYS a good idea to close ALL programs prior to performing an On Demand scan
>and so this measure makes sure these are auto-closed.
Does this kick in when Multi-AV starts, or when you initiate a scan in
Multi-AV? Because often one may run Multi-AV simply to update it.
>| It would be nice to checkbox these changes for interactive user
>| (de)selection, so the
>| user's more aware (and in control) of what is
>| being done. Then again, that may be hard
>| to UI in Kix
>Those options can be toggled on/off but it is meant to be simple and not
compliacted with
>lots of various operting parameters.
Yup, I know it's an ease-of-use tradeoff. An UI dialog box with a
Settings... button would be the best way to do this, but may require
more code-like development tools. Use of CLI parameters would be good
for geeks, but not as useful for others.
>I see no reason for them to be disabled anyway. As I wrote one should
>always close ALL programs before performing an On Demand scan
Well, ideally you shouldn't be running the infected code base at all,
but right now it's hard to craft an "easy to use" solution there.
If it does these terminations just before doing a scan, or perhaps a
wizard that runs all scans consecutively, then there's less need to
avoid this behavior, but it is a pain if it does this whenever
multi-AV starts up. For example, one might be updating a number of
different things prior to a site job or whatever, and thus have
downloads in progress via web browsers, when starting up Multi-AV so
that it can pull updates for its scanners.
>If I was to include such a capability I could create an INI file that can
>have the prarameters set to YES or NO so it can be easily programmed
>and easily manipulated by the End User. Such an INI file could be
>edited from within the Menu.
That could be good; one could also pass an .ini filespec to Multi-AV
as it starts up, so that different UI shortcuts can be used to run it
in different ways. Combining shortcut Properties with CLI-driven
engines is an easy way to make CLI tools easier to use, and your use
of a hard-coded installation path makes it easier to provide such
shortcuts with the package.
The two custom-coded things I'd like to see are:
1) Generic GUI front-end for CLI scanners
2) Log interpreter / aggregator
Both could use .INI files to "drive" them.
The first would map UI elements to CLI parameters, so you could run a
CLI scanner from the GUI front-end and select what to scan, whether to
clean, where to save the report, whether to scan in archives etc. from
the GUI and have the relevant .INI file translate these UI choices to
an appropriate command line to run the CLI scanner.
The second would parse the log file produced by the CLI scanner, and
extract filespec, malware name and result for whatever was detected.
The .INI file would drive this process by providing the needed text
cues. Then the raw results would be re-formulated in a certain way
and appended to a given report filespec.
You could also use (1) to pre-configure command lines for use from a
"wizard" batch file that would run numerous CLI scanners in series,
invoking (2) after each scan to build up a common log file.
>--------------- ---- --- -- - - - -
Saws are too hard to use.
Be easier to use!
>--------------- ---- --- -- - - - -
|
|
Posted by David H. Lipman on March 11, 2007, 10:44 am
If you were Registered and logged in, you could reply and use other advanced thread options
| On Sat, 3 Mar 2007 08:00:21 -0500, "David H. Lipman"
>> From: "cquirke (MVP Windows shell/user)"
|
>|> It also may close web browsers when it runs?
|
>> It will Kill the processes of; Firefox, IE and Opera by design to keep them
from holding
>> malware file handles open as well as any malware that may bu using their
names. It is
>> ALWAYS a good idea to close ALL programs prior to performing an On Demand scan
>> and so this measure makes sure these are auto-closed.
|
| Does this kick in when Multi-AV starts, or when you initiate a scan in
| Multi-AV? Because often one may run Multi-AV simply to update it.
|
The Process Kill functions are performed on the scan, not in th menu.
>|> It would be nice to checkbox these changes for interactive user
>|> (de)selection, so the
>|> user's more aware (and in control) of what is
>|> being done. Then again, that may be hard
>|> to UI in Kix
|
>> Those options can be toggled on/off but it is meant to be simple and not
compliacted with
>> lots of various operting parameters.
|
| Yup, I know it's an ease-of-use tradeoff. An UI dialog box with a
| Settings... button would be the best way to do this, but may require
| more code-like development tools. Use of CLI parameters would be good
| for geeks, but not as useful for others.
|
>> I see no reason for them to be disabled anyway. As I wrote one should
>> always close ALL programs before performing an On Demand scan
|
| Well, ideally you shouldn't be running the infected code base at all,
| but right now it's hard to craft an "easy to use" solution there.
|
| If it does these terminations just before doing a scan, or perhaps a
| wizard that runs all scans consecutively, then there's less need to
| avoid this behavior, but it is a pain if it does this whenever
| multi-AV starts up. For example, one might be updating a number of
| different things prior to a site job or whatever, and thus have
| downloads in progress via web browsers, when starting up Multi-AV so
| that it can pull updates for its scanners.
|
>> If I was to include such a capability I could create an INI file that can
>> have the prarameters set to YES or NO so it can be easily programmed
>> and easily manipulated by the End User. Such an INI file could be
>> edited from within the Menu.
|
| That could be good; one could also pass an .ini filespec to Multi-AV
| as it starts up, so that different UI shortcuts can be used to run it
| in different ways. Combining shortcut Properties with CLI-driven
| engines is an easy way to make CLI tools easier to use, and your use
| of a hard-coded installation path makes it easier to provide such
| shortcuts with the package.
|
| The two custom-coded things I'd like to see are:
|
| 1) Generic GUI front-end for CLI scanners
|
| 2) Log interpreter / aggregator
|
| Both could use .INI files to "drive" them.
|
| The first would map UI elements to CLI parameters, so you could run a
| CLI scanner from the GUI front-end and select what to scan, whether to
| clean, where to save the report, whether to scan in archives etc. from
| the GUI and have the relevant .INI file translate these UI choices to
| an appropriate command line to run the CLI scanner.
|
| The second would parse the log file produced by the CLI scanner, and
| extract filespec, malware name and result for whatever was detected.
| The .INI file would drive this process by providing the needed text
| cues. Then the raw results would be re-formulated in a certain way
| and appended to a given report filespec.
|
| You could also use (1) to pre-configure command lines for use from a
| "wizard" batch file that would run numerous CLI scanners in series,
| invoking (2) after each scan to build up a common log file.
|
I think you read too much of the idea of that INI file. :-)
--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm
|
| Similar Threads | Posted | | Re: Bad McAfee update caused browsing problems | August 4, 2007, 5:57 pm |
| URL problem | April 4, 2007, 3:50 pm |
| Very odd dns problem | July 5, 2007, 4:23 pm |
| W32.alcra.b problem | July 1, 2005, 2:34 pm |
| Please Help! Problem with Start Up!! | August 27, 2005, 11:35 am |
| VundoFix - another problem | September 8, 2005, 2:20 am |
| possible virus problem... help!!!! | November 24, 2005, 1:56 pm |
| spyware problem | December 10, 2005, 11:39 pm |
| PROBLEM WITH FIREWALL AND IIS | December 23, 2005, 3:01 pm |
| Problem getting rid of TROJ_AGENT.AMV | February 10, 2006, 6:58 am |
|
XML site map