Re: Workarounds that kill Active-X controls.
- From: Mark V <notvalid@xxxxxxxxxxx>
- Date: Thu, 05 Oct 2006 14:25:08 -0400
In microsoft.public.win2000.registry Jim Nugent wrote:
In news:Xns9852BA1714263z9zzaQ2btw@xxxxxxxxxxxxxxxxxxxx,
Mark V <notvalid@xxxxxxxxxxx> wrote:
Making a Full Registry Backup in advance would be *good*!
Short of that an Export saved for reference would be also be
useful.
I make a lot of registry back ups but in this case I also export
the key, if it exists, as a workaround "undo" file before
replacing the Compatibility Flags value with 0x400.
Good technique, but many typical user are no where near so savvy.
Unfortunately.
Both the REG files I have seen and I believe the dedicated EXE
tools for this "set a kill bit" ignore the possibility of an
existing Compatibility Flag value might be present. Not so
good.
Hmmm... Here's one: killWebView(926043)_undo.reg
------------------------
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{E5DF9D10-3B52-11D1-83E8-00A0C90DC849}]
"Compatibility Flags"=dword:00020000
-----------------------
Which is "handy" for some but again there is an assumption that in
fact that _was_ the existing value.
[ ]
Yes, there are some empty keys in there. Exporting them before
adding Compatibility Flags would create a undo.reg file that
would restore their "empty" status.
Unless they did not exist previously...
Yup. I tracked down the keys for the two outstanding workarounds
on machines without the w/a's. For the published workarounds,
the key above is the only key I found
present, complete with flags. But somebody should check my work.
In the recent WebViewFoldrIcon (.1 and .2) case
(ref: http://isc.sans.org/diary.php?date=2006-10-01 )
I had only one key present here at the outset. So to really
"undo" I will have to remove the entire key at a future date. Any
future undo REG file for example may do just that and that could be
the wrong thing altogether in some cases. <sigh>
I'd prefer to see (for typical users) small executables (from
trustworthy sources) for such emergency killbit operations that are
responsible and store in the registry any former value and be
capable of restoring same on the second run.
[ ]
[ ]I should mention a GUI tool: Nirsoft's ACM (ActiveX
Compatibility Manager) (free) nirsoft.net
This tool does _not_ save existing Compatibility Flags data
when "disable" is selected. Also has a limited CLI usage.
Also for anyone interested, their other tool, Active X Helper,
"disables" a control not with the kill bit but by munging the
value name for the control's path, e.g.
Absolutely! And the fact that both tools use "Disable" for action
is bad along with ACM not being very in-your-face about it is
actually dealing with "kill bits" and probably _adding_ new keys in
some cases. These two also suffer from a look-a-like (too much)
problem in my opinion. "Active X Helper" is also a misnomer since
all registered objects, not just ActiveX controls, are initially
displayed.
Enabling returns it the former. I guess that would disable
the control for ANY use, including IE scripting.
Right, but that action is at least reversible.
Hope all this makes sense,
It does. But the naming of and displays in several of Nir's tools
does not! Gotta remember to write him one of these days.
Some users may find ERUNT to be a great way to easily make Full
Registry Backups that can serve (for a while) as historical
references.
Think I saw you over at GRC recently? I hang out there often
enough.
.
- References:
- Re: Workarounds that kill Active-X controls.
- From: Mark V
- Re: Workarounds that kill Active-X controls.
- From: Jim Nugent
- Re: Workarounds that kill Active-X controls.
- Prev by Date: Re: Registry Colum Order
- Next by Date: Pagefile Cleanup
- Previous by thread: Re: Workarounds that kill Active-X controls.
- Next by thread: Re: Workarounds that kill Active-X controls.
- Index(es):
Relevant Pages
|
Loading
