Blank app name in "open with ..." list

From somewhere at some time in the past (I don't use this all that
often) a new entry has appeared at the top of the app-list in the
"open with ..." selection box. It has the generic .exe icon (white
box with blue title bar at the top) and a blank name.

If I select say a .txt file on the desktop and try to open it with
this blank-named app, I get a WinExploder window showing C:\ - and NOT
in the normally selected view options either.

While it (presumably) isn't doing any harm, I would like to get rid of
it. But how - there is of course no corresponding entry in the
ControlPanel-Add/RemovePrograms list.

who where wrote in
:

From somewhere at some time in the past (I don't use this all that
often) a new entry has appeared at the top of the app-list in the
"open with ..." selection box. It has the generic .exe icon (white
box with blue title bar at the top) and a blank name.

If I select say a .txt file on the desktop and try to open it with
this blank-named app, I get a WinExploder window showing C:\ - and NOT
in the normally selected view options either.

While it (presumably) isn't doing any harm, I would like to get rid of
it. But how - there is of course no corresponding entry in the
ControlPanel-Add/RemovePrograms list.

Got to work backwards to fix that one. Start by exporting the whole registry
to a file on the destop.

Open in a text editor. A good one, Notepad won't touch this...

Search for this exact string:
\shell\open\command]

Look at the line immediately below each occurence (of many) that you will
find. Look for anything that does not look like a standard path.
@="D:\\ZoodleWurdle.exe %1" Is a valid path, it has a double ('escaped')
backslash in it, meaning a single one will appear correctly in the registry
editor if you look at it there. The %1 passes the filename you're asking it
to handle. Most if not all occurences will be like this, so look for one that
is not. If the actual file a valid path points to is absent, you'll get an
access error message, not what you saw.

This broken path thing WILL cause the event you saw, a basic Explorer view of
the root of the install drive (Usually C:\), but there may be other ways. If
you DO find some broken path, look at the base of the branch, the bit
immediately before \shell\open\command] and search for that in the registry
editor. You should find two occurences (plus at least one duplicate of each
in another part of the registry). The first is the filetype (rooted as .lll
or some such, basically the file extension), the second is the association,
rooted by the specific name you found immediately before \shell\open\command]
which you just searched for. Delete both branches, and the blank entry will
also vanish.

When you figure out what original association broke, and want it back, set it
up as normal, using Open With, etc...

On Nov 18, 6:54*am, Lostgallifreyan wrote:
who where wrote :

From somewhere at some time in the past (I don't use this all that
often) a new entry has appeared at the top of the app-list in the
"open with ..." selection box. *It has the generic .exe icon (white
box with blue title bar at the top) and a blank name.

If I select say a .txt file on the desktop and try to open it with
this blank-named app, I get a WinExploder window showing C:\ - and NOT
in the normally selected view options either.

While it (presumably) isn't doing any harm, I would like to get rid of
it. *But how - there is of course no corresponding entry in the
ControlPanel-Add/RemovePrograms list.

Got to work backwards to fix that one. Start by exporting the whole registry
to a file on the destop.

Open in a text editor. A good one, Notepad won't touch this...

Search for this exact string:
\shell\open\command]

Look at the line immediately below each occurence (of many) that you will
find. Look for anything that does not look like a standard path.
@="D:\\ZoodleWurdle.exe %1" Is a valid path, it has a double ('escaped')
backslash in it, meaning a single one will appear correctly in the registry
editor if you look at it there. The %1 passes the filename you're asking it
to handle. Most if not all occurences will be like this, so look for one that
is not. If the actual file a valid path points to is absent, you'll get an
access error message, not what you saw.

This broken path thing WILL cause the event you saw, a basic Explorer view of
the root of the install drive (Usually C:\), but there may be other ways. If
you DO find some broken path, look at the base of the branch, the bit
immediately before \shell\open\command] and search for that in the registry
editor. You should find two occurences (plus at least one duplicate of each
in another part of the registry). The first is the filetype (rooted as .lll
or some such, basically the file extension), the second is the association,
rooted by the specific name you found immediately before \shell\open\command]
which you just searched for. Delete both branches, and the blank entry will
also vanish.

When you figure out what original association broke, and want it back, set it
up as normal, using Open With, etc...

I duplicated the OP's entry by modifiying the .com file entry with a
leading space, like so.

REGEDIT4

[HKEY_CLASSES_ROOT\comfile\shell\open\command]
@=" \"%1\" %*"

normally it's supposed be like this
REGEDIT4

[HKEY_CLASSES_ROOT\comfile\shell\open\command]
@="\"%1\" %*"

Probably easier to just use regedit's search function on the word
command than export the entire registry. Pressing F3 searches from
where you left off so nonsense entries and entries that do not apply
are quickly passed by.

Lee wrote in news:f30428d2-5fe5-41f2-991c-
:

Probably easier to just use regedit's search function on the word
command than export the entire registry. Pressing F3 searches from
where you left off so nonsense entries and entries that do not apply
are quickly passed by.


Can be. I like to export them because TextPad is especially good at this sort
of editing, uses RegExp, etc. That and I like to stay familiar with reg file
innards, it makes things easier for me.

About that preceding space, did it fix immediately if you restored proper
format? When I was experimenting I thought I saw an odd persistence implying
some extra mechanism I didn't find. (Interestingly, at least one standard
Windows default command format in there is borked. I can't remember which
one, but it had mismatched quotes (an odd number, not even) and wouldn't take
longnames with spaces. This error was in the default install or W98.)

On Fri, 18 Nov 2011 07:54:06 -0600, Lostgallifreyan
wrote:

Got to work backwards to fix that one. Start by exporting the whole registry
to a file on the destop.

Open in a text editor. A good one, Notepad won't touch this...

Search for this exact string:
\shell\open\command]

Look at the line immediately below each occurence (of many) that you will
find. Look for anything that does not look like a standard path.
%1" Is a valid path, it has a double ('escaped')
backslash in it, meaning a single one will appear correctly in the registry
editor if you look at it there. The %1 passes the filename you're asking it
to handle. Most if not all occurences will be like this, so look for one that
is not. If the actual file a valid path points to is absent, you'll get an
access error message, not what you saw.

After getting cramps in my left hand, arched over the kbd above the F3
key, I have hopefully found all such entries and Ctrl-C/Ctrl-V-ed the
suspicious ones to a notepad file so that they can be revisited in
less than the hour this took.

There were many "well-formed" as per your example. There were almost
as many of the form @="rundll32.exe shdocvw.dll,OpenURL %l" also.

There was one which explicitly invoked Explorer /root:


[HKEY_LOCAL_MACHINE\Software\CLASSES\CLSID\{0CD7A5C 0-9F37-11CE-AE65-08002B2E1262}\shell\open]
@="View"


[HKEY_LOCAL_MACHINE\Software\CLASSES\CLSID\{0CD7A5C 0-9F37-11CE-AE65-08002B2E1262}\shell\open\command]
@="explorer /root,{0CD7A5C0-9F37-11CE-AE65-08002B2E1262},%1"

That key in regedit is tagged "Cabinet"

There were threee of the form

[HKEY_LOCAL_MACHINE\Software\CLASSES\exefile\shell\ open]
@=""
"EditFlags"=hex:00,00,00,00


[HKEY_LOCAL_MACHINE\Software\CLASSES\exefile\shell\ open\command]
@="\"%1\" %*"

(the "wrap" is there) for exe, com and bat files - which seemed
credible.

The occurrence of


[HKEY_LOCAL_MACHINE\Software\CLASSES\InterTrustSPOP \shell\open]


[HKEY_LOCAL_MACHINE\Software\CLASSES\InterTrustSPOP \shell\open\command]
@=""

refused to copy/paste, appearing instead as

[HKEY_LOCAL_MACHINE\Software\CLASSES\ASFFile\shell\ open]
@="&Open"


[HKEY_LOCAL_MACHINE\Software\CLASSES\ASFFile\shell\ open\command]
@="\"C:\\PROGRAM FILES\\CCCP\\MPC\\MPLAYERC.EXE\" \"%1\""
"mplayerc.exe.bak"="\"C:\\PROGRA~1\\WINDOW~1\\mpla yer2.exe\"
/Play \"%L\""

That is a WTF.

and there was one more with that same double-ext
"mplayerc.exe.bak"="".


This broken path thing WILL cause the event you saw, a basic Explorer view of
the root of the install drive (Usually C:\), but there may be other ways. If
you DO find some broken path, look at the base of the branch, the bit
immediately before \shell\open\command] and search for that in the registry
editor. You should find two occurences (plus at least one duplicate of each
in another part of the registry). The first is the filetype (rooted as .lll
or some such, basically the file extension), the second is the association,
rooted by the specific name you found immediately before \shell\open\command]
which you just searched for. Delete both branches, and the blank entry will
also vanish.

None of the above that I found help me with that step in regedit. Can
you see anything among them that I should pursue?

When you figure out what original association broke, and want it back, set it
up as normal, using Open With, etc...

BTW, did you copy/paste this post or free-type it? If the latter, you
deserve a medal.

who where wrote in
:

On Fri, 18 Nov 2011 07:54:06 -0600, Lostgallifreyan
wrote:

Got to work backwards to fix that one. Start by exporting the whole
registry to a file on the destop.

Open in a text editor. A good one, Notepad won't touch this...

Search for this exact string:
\shell\open\command]

Look at the line immediately below each occurence (of many) that you
will find. Look for anything that does not look like a standard path.
%1" Is a valid path, it has a double ('escaped')
backslash in it, meaning a single one will appear correctly in the
registry editor if you look at it there. The %1 passes the filename
you're asking it to handle. Most if not all occurences will be like
this, so look for one that is not. If the actual file a valid path
points to is absent, you'll get an access error message, not what you
saw.

After getting cramps in my left hand, arched over the kbd above the F3
key, I have hopefully found all such entries and Ctrl-C/Ctrl-V-ed the
suspicious ones to a notepad file so that they can be revisited in
less than the hour this took.

There were many "well-formed" as per your example. There were almost
as many of the form @="rundll32.exe shdocvw.dll,OpenURL %l" also.

There was one which explicitly invoked Explorer /root:


[HKEY_LOCAL_MACHINE\Software\CLASSES\CLSID\{0CD7A5C 0-9F37-11CE-AE65-08002
B2E1262}\shell\open]
@="View"


[HKEY_LOCAL_MACHINE\Software\CLASSES\CLSID\{0CD7A5C 0-9F37-11CE-AE65-08002
B2E1262}\shell\open\command]
@="explorer /root,{0CD7A5C0-9F37-11CE-AE65-08002B2E1262},%1"

That key in regedit is tagged "Cabinet"

There were threee of the form

[HKEY_LOCAL_MACHINE\Software\CLASSES\exefile\shell\ open]
@=""
"EditFlags"=hex:00,00,00,00


[HKEY_LOCAL_MACHINE\Software\CLASSES\exefile\shell\ open\command]
@="\"%1\" %*"

(the "wrap" is there) for exe, com and bat files - which seemed
credible.

The occurrence of


[HKEY_LOCAL_MACHINE\Software\CLASSES\InterTrustSPOP \shell\open]


[HKEY_LOCAL_MACHINE\Software\CLASSES\InterTrustSPOP \shell\open\command]
@=""

refused to copy/paste, appearing instead as

[HKEY_LOCAL_MACHINE\Software\CLASSES\ASFFile\shell\ open]
@="&Open"


[HKEY_LOCAL_MACHINE\Software\CLASSES\ASFFile\shell\ open\command]
@="\"C:\\PROGRAM FILES\\CCCP\\MPC\\MPLAYERC.EXE\" \"%1\""
"mplayerc.exe.bak"="\"C:\\PROGRA~1\\WINDOW~1\\mpla yer2.exe\"
/Play \"%L\""

That is a WTF.

and there was one more with that same double-ext
"mplayerc.exe.bak"="".


This broken path thing WILL cause the event you saw, a basic Explorer
view of the root of the install drive (Usually C:\), but there may be
other ways. If you DO find some broken path, look at the base of the
branch, the bit immediately before \shell\open\command] and search for
that in the registry editor. You should find two occurences (plus at
least one duplicate of each in another part of the registry). The first
is the filetype (rooted as .lll or some such, basically the file
extension), the second is the association, rooted by the specific name
you found immediately before \shell\open\command] which you just
searched for. Delete both branches, and the blank entry will also
vanish.

None of the above that I found help me with that step in regedit. Can
you see anything among them that I should pursue?

When you figure out what original association broke, and want it back,
set it up as normal, using Open With, etc...

BTW, did you copy/paste this post or free-type it? If the latter, you
deserve a medal.

I copied the \shell\open\command] bit.

The Rundll commands run a DLL like an EXE, getting some internal function.
The Open With entries will rarely if ever take that form.

I still don't know about EditFlags, when I encounter that I either leave as is,
or omit if I can see nothing bad resulting. In saved REG files, I comment a
line with preceding semicolon if in doubt.

The one that refused to copy/paste isn't the same branch before copy and after
paste so double-check that one... if the issue is just the '&Open' bit, that
could just mean it assumes a default must exist for handling, so creates one.
That & is useful, it sets where the menu underline goes for keyboard shortcuts.
Renaming entries and editing those can make a BIG difference to fast keyboard
access to stuff. These registry entries offer a lot of customisable control...

The mplayerc.exe.bak thing might be something specific to the CCCP codec pack,
if it installs its own version of a player. It appears to keep an older copy it
found (in this case the original Windows Media Player v6, probably), to try in
case its own fails to handle something. All this is guessing...

Lee's post mentions that a preceding space can cause what you saw in the
'Open With' dialog. Sometimes it can be hard to spot these things, harder still
to prevent them, but as you're ok with this kind of effort, take a look at a
couple of posts I made last night, for a template for file associations.
They won't always take that form, they're often more complex, but once you install
some program you trust, especially audio tools (because they often fight for
ownership of many file types), export the types and associations from registry,
and clean out any [HKEY.../xxxx/yyyy..] lines that have NO text immediately below
them, to lighten the weight a bit, and make the top level ones copied right under
REGEDIT4 with the dash inside the first [ bracket. This way if it ever borks, or
something steals file types, you can use that saved file to instantly fix it.

THis method sounds tedious, but it's no harder than the work you already did.
Also, it is a good basis for automatic reinstalls of many programs after a fresh
Windows install. With REG files, and a batch file to call them and do a few sysfile
copies, the equivalent of a large electronic music studio can be installed to a
new machine with one double-click this way. The work needed to do it saves
incalculable amounts of other work, and it's easier to do than trying to
understand why some of the innards break the way they do at times.

On Nov 21, 5:27*am, Lostgallifreyan wrote:
Lee wrote in news:f30428d2-5fe5-41f2-991c-
:

Probably easier to just use regedit's search function on the word
command than export the entire registry. *Pressing F3 searches from
where you left off so nonsense entries and entries that do not apply
are quickly passed by.

Can be. I like to export them because TextPad is especially good at this sort
of editing, uses RegExp, etc. That and I like to stay familiar with reg file
innards, it makes things easier for me.

About that preceding space, did it fix immediately if you restored proper
format? When I was experimenting I thought I saw an odd persistence implying
some extra mechanism I didn't find. (Interestingly, at least one standard
Windows default command format in there is borked. I can't remember which
one, but it had mismatched quotes (an odd number, not even) and wouldn't take
longnames with spaces. This error was in the default install or W98.)

For me the fix was immediate, but there is a trick to use when such
registry changes are NOT immediate - go to Start|Shut Down and select
cancel. The creation of the Shut Down dialog box rewrites any current
ShellIconCache file and pending registry changes such that once you
cancel the shutdown, your registry has different contents. At least
sometimes.

I was going to dive into a diatribe on how spaces were not allowed in
longnames no matter what the quote pair count situation was, but then
I saw evidence to the contrary so I thought it best not to speak on it
at all in my first post. By my "old" understanding it shouldn't have
worked out, but
""C:\Apps\Adobe\Acrobat 6.0\Reader\AcroRd32.exe" "%1""
does. It should have resulted in a dead end entry of ACROBAT but does
not. AcroRd32 instead is there with it's proper icon too. WTF? So
double quotes DO appear to work with spaces and longnames after all?

As a side note, I see that my ShellIconCache file has swelled to
6,613KB in size - anybody got a bigger one?

Errors such that you report as "This error was in the default install
on W98", I now believe are created by DOS mode hard disk write errors
at installation time. Usually happens only to cheap crap machines
with permanently broke DMA like mine which in the early days of 98
required a re-installation of Windows almost quarterly. And because I
was such a dangerous fool, I often got it without asking for it. Not
so much lately, but then I've got DMA working properly from DOS mode
now. And that would be applied before DOS mode Vmm32.vxd et.al. gets
loaded. Which totally explains why the VXD fix worked so good for me
way back then against ALL advice to the contrary from the sage
pundits. Sage pundits apparently can afford better machines than I
can and don't suffer the problem to begin with.

On Nov 21, 5:42*am, who where wrote:
On Fri, 18 Nov 2011 07:54:06 -0600, Lostgallifreyan





wrote:
Got to work backwards to fix that one. Start by exporting the whole registry
to a file on the destop.

Open in a text editor. A good one, Notepad won't touch this...

Search for this exact string:
\shell\open\command]

Look at the line immediately below each occurence (of many) that you will
find. Look for anything that does not look like a standard path.
%1" Is a valid path, it has a double ('escaped')
backslash in it, meaning a single one will appear correctly in the registry
editor if you look at it there. The %1 passes the filename you're asking it
to handle. Most if not all occurences will be like this, so look for one that
is not. If the actual file a valid path points to is absent, you'll get an
access error message, not what you saw.

After getting cramps in my left hand, arched over the kbd above the F3
key, I have hopefully found all such entries and Ctrl-C/Ctrl-V-ed the
suspicious ones to a notepad file so that they can be revisited in
less than the hour this took.

There were many "well-formed" as per your example. *There were almost
as many of the form @="rundll32.exe shdocvw.dll,OpenURL %l" also.

There was one which explicitly invoked Explorer /root:

[HKEY_LOCAL_MACHINE\Software\CLASSES\CLSID\{0CD7A5C 0-9F37-11CE-AE65-08002B2*E1262}\shell\open]
* * * * @="View"

[HKEY_LOCAL_MACHINE\Software\CLASSES\CLSID\{0CD7A5C 0-9F37-11CE-AE65-08002B2*E1262}\shell\open\command]
* * * * @="explorer /root,{0CD7A5C0-9F37-11CE-AE65-08002B2E1262},%1"

That key in regedit is tagged "Cabinet"

There were threee of the form

* * * * [HKEY_LOCAL_MACHINE\Software\CLASSES\exefile\shell\ open]
* * * * @=""
* * * * "EditFlags"=hex:00,00,00,00

[HKEY_LOCAL_MACHINE\Software\CLASSES\exefile\shell\ open\command]
* * * * @="\"%1\" %*"

(the "wrap" is there) for exe, com and bat files - which seemed
credible.

The occurrence of

[HKEY_LOCAL_MACHINE\Software\CLASSES\InterTrustSPOP \shell\open]

[HKEY_LOCAL_MACHINE\Software\CLASSES\InterTrustSPOP \shell\open\command]
* * * * @=""

refused to copy/paste, appearing instead as

* * * * [HKEY_LOCAL_MACHINE\Software\CLASSES\ASFFile\shell\ open]
* * * * @="&Open"

[HKEY_LOCAL_MACHINE\Software\CLASSES\ASFFile\shell\ open\command]
* * * * @="\"C:\\PROGRAM FILES\\CCCP\\MPC\\MPLAYERC.EXE\" \"%1\""
* * * * "mplayerc.exe.bak"="\"C:\\PROGRA~1\\WINDOW~1\\mpla yer2.exe\"
/Play \"%L\""

That is a WTF.

and there was one more with that same double-ext
"mplayerc.exe.bak"="".

This broken path thing WILL cause the event you saw, a basic Explorer view of
the root of the install drive (Usually C:\), but there may be other ways.. If
you DO find some broken path, look at the base of the branch, the bit
immediately before \shell\open\command] and search for that in the registry
editor. You should find two occurences (plus at least one duplicate of each
in another part of the registry). The first is the filetype (rooted as .lll
or some such, basically the file extension), the second is the association,
rooted by the specific name you found immediately before \shell\open\command]
which you just searched for. Delete both branches, and the blank entry will
also vanish.

None of the above that I found help me with that step in regedit. *Can
you see anything among them that I should pursue?

When you figure out what original association broke, and want it back, set it
up as normal, using Open With, etc...

BTW, did you copy/paste this post or free-type it? *If the latter, you
deserve a medal.- Hide quoted text -

- Show quoted text -

The comfile mod that I "found" does open Windows Explorer in single
pane web view as you describe, perhaps take off your glasses and look
closer at that single entry? Real close.

It almost has to be an extra leading space in an un-named executable
entry.

Dan Rather said if it walks like a duck and quacks like a duck then it
probably is a duck, but then he also said about his career ending Bush
snafu "it could be true so it probably is". There has to be a point
in there somewhere? maybe not

Lee wrote in news:611be992-64d4-4b4a-b074-
:

For me the fix was immediate, but there is a trick to use when such
registry changes are NOT immediate - go to Start|Shut Down and select
cancel. The creation of the Shut Down dialog box rewrites any current
ShellIconCache file and pending registry changes such that once you
cancel the shutdown, your registry has different contents. At least
sometimes.


The registry updates immediately, but the stuff that has to read it might
not. I didn't know that the shurdown dialog would cause the shell to do this,
and I suspect it may be limited, but there is a related method that always
forces a complete shell reload: Ctrl+Alt+Del, click Explorer in the list,
then click the End Task button. This will bring uo the Shutdown dialog but
click NO. And wait. Eventually the End Task dialog pops up asking if you
want to shut down Explorer. This time click YES, and it will immediately
close and restart. Not that any active system tray icons vanish, and a few
other quirks result, but this can bail a person out of a broken session where
it is critical that some program remains running. If you develop a massive
GDI memory leak during a major XviD encode, for example. This might at least
get you a fresh shell that won't crash, allowing safe monitoring of the task
that has to complete.

I was going to dive into a diatribe on how spaces were not allowed in
longnames no matter what the quote pair count situation was, but then
I saw evidence to the contrary so I thought it best not to speak on it
at all in my first post. By my "old" understanding it shouldn't have
worked out, but
""C:\Apps\Adobe\Acrobat 6.0\Reader\AcroRd32.exe" "%1""
does. It should have resulted in a dead end entry of ACROBAT but does
not. AcroRd32 instead is there with it's proper icon too. WTF? So
double quotes DO appear to work with spaces and longnames after all?


Yep, it definitely does. If you look at that command you'll see the %1 is
also quoted. In many cases it isn't! THis is one of the less important errors
in default registries, but it explains why some programs can't take filenames
with spaces wven if the path to the program can because that part of the
command does (usually) get its quotes.

Try omitting one quote while keeping the other. That might get you a blank
entry in Open With, perhaps.. Or at least a blank look from the OS.

As a side note, I see that my ShellIconCache file has swelled to
6,613KB in size - anybody got a bigger one?


Smaller here.

Errors such that you report as "This error was in the default install
on W98", I now believe are created by DOS mode hard disk write errors
at installation time. Usually happens only to cheap crap machines
with permanently broke DMA like mine which in the early days of 98
required a re-installation of Windows almost quarterly. And because I
was such a dangerous fool, I often got it without asking for it. Not
so much lately, but then I've got DMA working properly from DOS mode
now. And that would be applied before DOS mode Vmm32.vxd et.al. gets
loaded. Which totally explains why the VXD fix worked so good for me
way back then against ALL advice to the contrary from the sage
pundits. Sage pundits apparently can afford better machines than I
can and don't suffer the problem to begin with.


I worked on building VMM32 last year, there's no doubt that some static, real
mode VXD's can be replaced with newer and better ones. Most are ok though.

Thing is, the registry paths thing wouldn't be related to a disk failure, or
if it was, then far more diabolical things are likely to get noticed first.
At that early stage in boot, significant troubles likely result in protected
mode errors, and Windows won't boot at all, the machine usually shuts right
down cold so fast we don't even get time to read why.

There may be situations that cause multiple errors to appear (or just get
noticed because we start lookign closely), but the mismatched quotes thing is
almost certainly a typo by someone at Microsoft. If you examine the few
filetypes and associations in a small 98-Lite instal you'll see enough of
them. I suppose it's possible that Shane Broosk did it. I think not
though, that stuff usually gets hoiked out of standard INF files at install
time. INF files are so tortuous that human error does creep into them, a lot.

On Mon, 21 Nov 2011 07:19:31 -0600, Lostgallifreyan
wrote:

who where wrote in
:

(snip)
BTW, did you copy/paste this post or free-type it? If the latter, you
deserve a medal.

I copied the \shell\open\command] bit.

that's a relief to hear ;-)

The Rundll commands run a DLL like an EXE, getting some internal function.
The Open With entries will rarely if ever take that form.

There were definitely a few like:

[HKEY_LOCAL_MACHINE\Software\CLASSES\InternetShortc ut\shell\open]
"CLSID"="{FBF23B40-E3F0-101B-8488-00AA003E56F8}"

[HKEY_LOCAL_MACHINE\Software\CLASSES\InternetShortc ut\shell\open\command]
@="rundll32.exe shdocvw.dll,OpenURL %l"


I still don't know about EditFlags, when I encounter that I either leave as is,
or omit if I can see nothing bad resulting. In saved REG files, I comment a
line with preceding semicolon if in doubt.

The one that refused to copy/paste isn't the same branch before copy and after
paste so double-check that one...

I just re-exported HKLM/Software/CLASSES and found it again. This
time it copied/pasted faithfully. I guess that was just a PEBKAC
moment, even though i did it several times in my disbelief.

You didn't think anything odd/coincidental that the one opening
Explorer/root happened to mimic the action of the subject entry?

(snip)

The mplayerc.exe.bak thing might be something specific to the CCCP codec pack,
if it installs its own version of a player. It appears to keep an older copy it
found (in this case the original Windows Media Player v6, probably), to try in
case its own fails to handle something. All this is guessing...

Lee's post mentions that a preceding space can cause what you saw in the
'Open With' dialog. Sometimes it can be hard to spot these things, harder still
to prevent them, but as you're ok with this kind of effort, take a look at a
couple of posts I made last night, for a template for file associations.

Which posts? Where should I be looking?

They won't always take that form, they're often more complex, but once you install
some program you trust, especially audio tools (because they often fight for
ownership of many file types), export the types and associations from registry,
and clean out any [HKEY.../xxxx/yyyy..] lines that have NO text immediately below
them, to lighten the weight a bit, and make the top level ones copied right under
REGEDIT4 with the dash inside the first [ bracket. This way if it ever borks, or
something steals file types, you can use that saved file to instantly fix it.

THis method sounds tedious, but it's no harder than the work you already did.

which *was* tedious ....