Tip: no email program associated to perform the requested action

MAPI gives the following error:

There is no email program associated to perform the requested action.
Please install an eMail program or, if one is already installed,
create an association in the Default Programs control panel

And "creating an association" does no good

This is a screw up in the Windows registry. The current user's default
MAPI association is missing.

The following will restore Thunderbird as the user's MAPI association:


REGEDIT4

[HKEY_CURRENT_USER\Software\Clients\Mail]
@="Mozilla Thunderbird"

T wrote:

MAPI gives the following error:

There is no email program associated to perform the requested action.
Please install an eMail program or, if one is already installed,
create an association in the Default Programs control panel

And "creating an association" does no good

This is a screw up in the Windows registry. The current user's default
MAPI association is missing.

The following will restore Thunderbird as the user's MAPI association:

REGEDIT4

[HKEY_CURRENT_USER\Software\Clients\Mail]
@="Mozilla Thunderbird"

Installing Outlook installs full (extended) MAPI support (by depositing
the mapi32.dll file). Installing any other client purposting to support
MAPI only uses Simple MAPI (already included in Windows).

https://en.wikipedia.org/wiki/MAPI
https://support.microsoft.com/en-us/...-extended-mapi

http://kb.mozillazine.org/MAPI_Support

Says making Thunderbird the default client establishes it to use Simple
MAPI. I suppose if that didn't fix the problem (that TB wasn't using or
failing on SMAPI calls), you could switch to a different e-mail client
as the default handler (if you have one), and then back to TB.

Was Outlook on the host, and then Outlook got uninstalled leaving
Thunderbird behind?

While Windows XP was supposed to fix the DLL Hell problem by using
multiple WinSxS lib folders, looks like e-mail clients still suffered
DLL Hell with the mapi32.dll that different programs would **** up.

Not sure why the MAPI handler association would be an issue with
Thunderbird since it doesn't support Exchange accounts. I thought the
ExQuilla add-on (*not* free, and is also subscriptionware) had to get
installed into Tbird to add Exchange support.

So, why configure Thunderbird as the default MAPI handler when it
doesn't support simple MAPI? Just /how/ are you getting Thunderbird to
connect to an Exchange server since Thunderbird does not have native
Exchange (MAPI) support? Thunderbird can connect to an Exchange
/account/, but only if the Exchange admin has setup POP, IMAP, and SMTP
servers to work with Exchange to access those Exchange accounts.
However, Tbird would be using POP or IMAP and SMTP to access the
[Exchange] account, not MAPI.

On 2020-07-25 06:59, VanguardLH wrote:
T wrote:

MAPI gives the following error:

There is no email program associated to perform the requested action.
Please install an eMail program or, if one is already installed,
create an association in the Default Programs control panel

And "creating an association" does no good

This is a screw up in the Windows registry. The current user's default
MAPI association is missing.

The following will restore Thunderbird as the user's MAPI association:

REGEDIT4

[HKEY_CURRENT_USER\Software\Clients\Mail]
@="Mozilla Thunderbird"

Installing Outlook installs full (extended) MAPI support (by depositing
the mapi32.dll file). Installing any other client purposting to support
MAPI only uses Simple MAPI (already included in Windows).

https://en.wikipedia.org/wiki/MAPI
https://support.microsoft.com/en-us/...-extended-mapi

http://kb.mozillazine.org/MAPI_Support

Says making Thunderbird the default client establishes it to use Simple
MAPI. I suppose if that didn't fix the problem (that TB wasn't using or
failing on SMAPI calls), you could switch to a different e-mail client
as the default handler (if you have one), and then back to TB.

Was Outlook on the host, and then Outlook got uninstalled leaving
Thunderbird behind?

While Windows XP was supposed to fix the DLL Hell problem by using
multiple WinSxS lib folders, looks like e-mail clients still suffered
DLL Hell with the mapi32.dll that different programs would **** up.

Not sure why the MAPI handler association would be an issue with
Thunderbird since it doesn't support Exchange accounts. I thought the
ExQuilla add-on (*not* free, and is also subscriptionware) had to get
installed into Tbird to add Exchange support.

So, why configure Thunderbird as the default MAPI handler when it
doesn't support simple MAPI?

It has extensive MAPI support. I use it ALL THE TIME.
The 64 bit version even includes 32 bit support, although
Quick Books has a bug in it that can not communicate
with Thunderbird's extensive MAPI support unless you
install the 32 bit version of Thunderbird. I have no
32/b4 bit issues with other programs using MAPI to
communicate with Thunderbird

Just /how/ are you getting Thunderbird to
connect to an Exchange server since Thunderbird does not have native
Exchange (MAPI) support? Thunderbird can connect to an Exchange
/account/, but only if the Exchange admin has setup POP, IMAP, and SMTP
servers to work with Exchange to access those Exchange accounts.
However, Tbird would be using POP or IMAP and SMTP to access the
[Exchange] account, not MAPI.

That would be because it is not talking to an Exchange Server.



Hi Vanguard,

https://en.wikipedia.org/wiki/MAPI

Messaging Application Programming Interface (MAPI) is
an API for Microsoft Windows which allows programs
to become email-aware. While MAPI is designed to
be independent of the protocol, it is usually used
to communicate with Microsoft Exchange Server

You missed the "designed to be independent of the
protocol" part. Usually you are always right about
this kind of stuff. Do not worry, I WILL screw up
enough times in the future that you will get
your track record back. You get use to it.

:-)

You can reproduce the issue I described by opening
Windows Explorer and right clicking on a file. Then
select SentTo, Mail recipient.

If the error I gave pops up, check for the missing
registry entry I mentioned.

I do not have any clients using Exchange Servers.
I hate the things.

-T

T wrote:

On 2020-07-25 06:59, VanguardLH wrote:
T wrote:

MAPI gives the following error:

There is no email program associated to perform the requested action.
Please install an eMail program or, if one is already installed,
create an association in the Default Programs control panel

And "creating an association" does no good

This is a screw up in the Windows registry. The current user's default
MAPI association is missing.

The following will restore Thunderbird as the user's MAPI association:

REGEDIT4

[HKEY_CURRENT_USER\Software\Clients\Mail]
@="Mozilla Thunderbird"

Installing Outlook installs full (extended) MAPI support (by depositing
the mapi32.dll file). Installing any other client purposting to support
MAPI only uses Simple MAPI (already included in Windows).

https://en.wikipedia.org/wiki/MAPI
https://support.microsoft.com/en-us/...-extended-mapi

http://kb.mozillazine.org/MAPI_Support

Says making Thunderbird the default client establishes it to use Simple
MAPI. I suppose if that didn't fix the problem (that TB wasn't using or
failing on SMAPI calls), you could switch to a different e-mail client
as the default handler (if you have one), and then back to TB.

Was Outlook on the host, and then Outlook got uninstalled leaving
Thunderbird behind?

While Windows XP was supposed to fix the DLL Hell problem by using
multiple WinSxS lib folders, looks like e-mail clients still suffered
DLL Hell with the mapi32.dll that different programs would **** up.

Not sure why the MAPI handler association would be an issue with
Thunderbird since it doesn't support Exchange accounts. I thought the
ExQuilla add-on (*not* free, and is also subscriptionware) had to get
installed into Tbird to add Exchange support.

So, why configure Thunderbird as the default MAPI handler when it
doesn't support simple MAPI?

It has extensive MAPI support. I use it ALL THE TIME.

*YOU* mentioned Thunderbird, not that you were issuing MAPI calls from
other software.

http://kb.mozillazine.org/MAPI_Support
"Thunderbird's SimpleMAPI support is buggy."
"Outlook Express and Thunderbird don't support Extended MAPI."

Thunderbird only supports Simple MAPI (SMAPI). Extended MAPI (EMAPI) is
now called just MAPI, because Microsoft dropped supporting and including
Simple MAPI in Windows.

https://docs.microsoft.com/en-us/pre...api32-dll-stub

Thunderbird can only use Simple MAPI, but that's gone as of Windows 7
which went forward with [Extended] MAPI.

https://bugzilla.mozilla.org/show_bug.cgi?id=546889
(11 year-old ticket)
https://stackoverflow.com/questions/...ndows-7-64-bit
(10 years old)

Well, if Thunderbird only supports Simple MAPI, but Microsoft dropped it
in Windows 7 (64-bit version), how is Thunderbird to become the MAPI
handler? I remember other programs (besides Thunderbird) having
problems back in Windows 7 because SMAPI was missing. I would've
thought SMAPI, because it was a subset of 12 of the methods from EMAPI,
would still work. If SMAPI is a subset, you'd think those functions
calls from programs would get handled by EMAPI. Yet, programs that used
SMAPI started to fail. Perhaps it was the issue of mismatched bitwidth:
64-bit programs issuing called to a 32-bit library, and perhaps why
Microsoft provided fixmapi.exe.

https://docs.microsoft.com/en-us/off...k/mapi/fixmapi

I haven't done any programming to MAPI (or SMAPI, either) to know if
there are nuances in differences in their methods (functions), like
users noting MAPIResolveName() stopped working on Windows 7.

https://docs.microsoft.com/en-us/off...mming-overview

That notes they carried over the SMAPI MAPISendMail() method into EMAPI
which hints there isn't a one-to-one direct mapping from SMAPI to EMAPI.

https://docs.microsoft.com/en-us/pre...mapi-functions

That lists the methods that a program could call using SMAPI. the host
where I'm replying isn't used for programming, so I don't have the tools
to list the exports defined in the mapi32.dll file in Windows 10 to see
what methods are callable.

Ah, hold on, I have Nirsoft's DLLexportView on my home PC. From that
list, there are MAPISendMail and MAPIResolveName methods. In fact, each
of the 12 methods listed for Simple MAPI are available in mapi32.dll (I
looked at exports for mapi32.dll in both the System32 and SysWOW64
folders). Oops, wait a minute: MAPISendMailHelper() is listed for
SMAPI, but it don't see it as an export from mapi32.dll (which would be
EMAPI on my Windows 10 host).

https://docs.microsoft.com/en-us/win...sendmailhelper

Guess it's not needed if the message data isn't UUencoded. I just
remember lots of programs using SMAPI stopped working as of Win7 x64,
but I had been using MS Outlook for years before and after, so I didn't
get hit with the loss of SMAPI.

You might be fine in whatever program you issue MAPI calls because it
will use EMAPI. But your hint has Thunderbird designated the MAPI
handler, and Thunderbird only supports SMAPI. What happens when the
MAPI-enabled program attempts to call a method that is outside the SMAPI
that Thunderbird supports?


UPDATE:

Oy Vey, uffdah, I just realized before clicking Submit that you stated
you were defining the MAPI handler in the registry when, in fact, you
are designating the default *mail* handler. Argh, nix all the MAPI
discussion.

Knowing what is the mail handler lets you know to where to direct your
MAPI calls. However, you can use a shortcut with "mailto:" to open
whichever is the current default mail handler, and that obviously
doesn't use MAPI at all. I haven't dug into it, but I suspect the Send
To operation just does a mailto: by the program filling in the mailto's
fields, but it could also use MAPI ... provided the mail handler is
defined.

However, back to using MAPI in your other programs, I can't see
Thunderbird can handle any method calls from your program that are
outside of Simple MAPI that Thunderbird supports. If the default mail
handler is not define, even mailto will fail.

https://developer.yoast.com/blog/guide-mailto-links/
https://tools.ietf.org/html/rfc2368

That doesn't use a communications interface between processes. I don't
see that involves MAPI at all. It just passes strings as arguments to
the designated handler. If the handler isn't defined, yeah, the mailto
fails.

While the program instigating the error might've said it was a MAPI
error, the key you mentioned is defining the default handler for
[e]mail. Maybe your MAPI-capable program used MAPI to send data to the
default mail handler, but the default handler was not defined. I take
it that toggling Thunderbird's "Set as default" option (to off and back
on) didn't step on this registry entry to make Thunderbird the default
mail handler.

https://support.mozilla.org/en-US/kb...lt-mail-client

That registry key should get created or modified by whichever e-mail
client you designate is the default mail handler. For Thunderbird to be
the default, the "@" data item (the default value for the Mail key)
should specify Thunderbird (by whatever product name was used). I'm
currently using em Client as my default mail handler, so "eM Client" is
specified. For me with eM Client, that default handler is named at the
above key but defined at HKEY_CURRENT_USER\Software\eM Client. If you
specified the UWP/RT Mail app in Windows 10 was the default mail
handler, I suspect you'll see its app ID specified.

Maybe a MAPI-capable program was responsible for issuing the error
message, but it said "no email program associated", and nothing about a
failed MAPI call. The problem, and what you did, was to define the
default mail handler. Odd that Thunderbird wouldn't do that for you.

On 2020-07-26 19:44, VanguardLH wrote:
Maybe a MAPI-capable program was responsible for issuing the error
message, but it said "no email program associated", and nothing about a
failed MAPI call. The problem, and what you did, was to define the
default mail handler. Odd that Thunderbird wouldn't do that for you.

That was the jobs of Windows. When you set the default eMail
client, Windows is suppose to write that entry. I changed
it back and forth from other programs. Windows never
wrote out that entry

I find a lot of Windows 10 machine that seems to be "individuals"
lately. Just one machine acting weird.
"sfc /scannow" comes back perfect. So I tear my
hair out but eventually fix them.

T wrote:

On 2020-07-26 19:44, VanguardLH wrote:
Maybe a MAPI-capable program was responsible for issuing the error
message, but it said "no email program associated", and nothing about a
failed MAPI call. The problem, and what you did, was to define the
default mail handler. Odd that Thunderbird wouldn't do that for you.

That was the jobs of Windows. When you set the default eMail
client, Windows is suppose to write that entry. I changed
it back and forth from other programs. Windows never
wrote out that entry

I find a lot of Windows 10 machine that seems to be "individuals"
lately. Just one machine acting weird.
"sfc /scannow" comes back perfect. So I tear my
hair out but eventually fix them.

Programs are no longer allowed to make some changes, like which is the
default e-mail client, filetype associations, and so on. Malware did
that, too, so Microsoft decided that some settings should only be
allowed by the user.

For the e-mail client that I use, I told them that the "Set as default"
option within the program would not work in Windows 10. The user could
click the button to think they made the change, but it never happened.
Eventually they wised up and had their program open the Default Programs
wizard in Windows 10. Their program couldn't make the change, so they
prompted the user by dumping them in the Default Programs wizard, and
the user had to make a manual change.

https://social.msdn.microsoft.com/Fo...elopmentissues

Blocking programmatic changes to defaults was a security measure to
thwart malware that would do the same thing. The user thought they were
starting a good program, but malware slid in a look-alike clone. Users
thought double-clicking a file to load into a default handler, but
malware had changed the filetype association. Not all such defaults or
filetypes are protected. I've yet to find a Microsoft publication to
specify which are protected to require user intervention and which are
the old way and left to any process to change to whatever they like.

The only way I see this improving is if Microsoft used certificates for
code signing, so good+signed programs could make the changes. Code
signing would take time and likely cost money. Alas, back then, malware
figured out how to usurp certs, and why some Windows updates were to
update certs to "Revoked" status. Microsoft requires Authenticode for
Microsoft-tested drivers (WHQL program), so maybe they'll have to extend
that to user-mode programs. However, the user should still get a choice
of whether they lock-down their computer by disallowing any unsigned
processes, or open it up to allowing any process to make any changes,
including malware.

On 2020-07-27 09:15, VanguardLH wrote:
T wrote:

On 2020-07-26 19:44, VanguardLH wrote:
Maybe a MAPI-capable program was responsible for issuing the error
message, but it said "no email program associated", and nothing about a
failed MAPI call. The problem, and what you did, was to define the
default mail handler. Odd that Thunderbird wouldn't do that for you.

That was the jobs of Windows. When you set the default eMail
client, Windows is suppose to write that entry. I changed
it back and forth from other programs. Windows never
wrote out that entry

I find a lot of Windows 10 machine that seems to be "individuals"
lately. Just one machine acting weird.
"sfc /scannow" comes back perfect. So I tear my
hair out but eventually fix them.

Programs are no longer allowed to make some changes, like which is the
default e-mail client, filetype associations, and so on. Malware did
that, too, so Microsoft decided that some settings should only be
allowed by the user.

For the e-mail client that I use, I told them that the "Set as default"
option within the program would not work in Windows 10. The user could
click the button to think they made the change, but it never happened.
Eventually they wised up and had their program open the Default Programs
wizard in Windows 10. Their program couldn't make the change, so they
prompted the user by dumping them in the Default Programs wizard, and
the user had to make a manual change.

https://social.msdn.microsoft.com/Fo...elopmentissues

Blocking programmatic changes to defaults was a security measure to
thwart malware that would do the same thing. The user thought they were
starting a good program, but malware slid in a look-alike clone. Users
thought double-clicking a file to load into a default handler, but
malware had changed the filetype association. Not all such defaults or
filetypes are protected. I've yet to find a Microsoft publication to
specify which are protected to require user intervention and which are
the old way and left to any process to change to whatever they like.

The only way I see this improving is if Microsoft used certificates for
code signing, so good+signed programs could make the changes. Code
signing would take time and likely cost money. Alas, back then, malware
figured out how to usurp certs, and why some Windows updates were to
update certs to "Revoked" status. Microsoft requires Authenticode for
Microsoft-tested drivers (WHQL program), so maybe they'll have to extend
that to user-mode programs. However, the user should still get a choice
of whether they lock-down their computer by disallowing any unsigned
processes, or open it up to allowing any process to make any changes,
including malware.


Several times now, I have had to go straight to the registry

T wrote:

Several times now, I have had to go straight to the registry

Using the Default Apps wizard didn't work to change the default mail
handler? Or is it that the e-mail program didn't register itself as a
handler, so it is not listed in the Default Programs list?

Whether you use the Default Apps wizard or edit the registry yourself
(or programmatically), not all filetypes for e-mail may get associated
to that e-mail program. Sometimes you have to go into Default Programs,
click "Set defaults by app", click the app, and click Manage. However,
that still might not catch all the filetypes you want to associate to a
handler, like protocols. Click the "Choose default apps by protocol".

Editing the registry may not always work. You might change the default
e-mail handler, but don't you also want .eml files associated with that
e-mail program? Some protected filetypes will have a UserChoice
registry key along with a hash string. If you use the Windows wizard to
define the handler for a filetype, Windows will generate the hash
string. You deleting the hash or trying to edit it will not generate a
valid value, so Windows will revert back to the default handler. For
example:

HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\FileExts\.avi\UserChoice

has VLC.avi, the filetype association for VLC (my choice of AVI player),
and has the UserChoice subkey under which are the ProgID and a hash that
Windows created. Me editing the registry to change the filetype
association won't work, because I won't know a correct hash to generate.
The same, for me, for:

HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\FileExts\.eml\UserChoice

where ProgID = eM Client.File.eml, and a Windows-generated hash value to
prevent tampering by registry editing -- whether that be you using
regedit.exe or a program (both use the registry API).

Since you're discussing e-mail, another protected entry is:

HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell \Associations\UrlAssociations\mailto\UserChoice

Yep, that has the UserChoice subkey with ProgID and Hash data items.
You can't generate a valid hash key. It's a protected choice.

Not all filetypes are protected via UserChoice and Hash, but enough are
that programmatic modification is a bitch under Windows 10. It's
Microsoft's scheme to thwart malicious change. I did encounter where my
e-mail client's own option "Make default" did not work. I had to use
the Windows-supplied Default Apps wizard to make the change for it to
stick. The programmatic method of changing the default mail handler
that worked in older versions of Windows may not work in Windows 10.
Same for editing the registry.

In Windows 10, programs are learning they have to present the Default
Apps wizard to make sure the default handler is changed to the user's
choice. However, even then the user may have to go into the app chosen
as the default handler to check all the filetypes are assigned to it.
After making eM Client my default e-mail program using their Default
Apps wizard, I still had to go to "Set defaults by app" to get some
filetypes changed to use eM Client as their handler.

You can try editing the registry to see if it sticks. Reboot Windows to
verify the change stuck. Else, you're stuck using the Windows wizards
to make changes since those know how to generate a valid hash value.

https://www.winhelponline.com/blog/s...ne-windows-10/

Looks like someone figured out a workaround; see:

http://kolbi.cz/blog/2017/10/25/setu...ions-per-user/
https://danysys.com/set-file-type-as...ternal-method/

Since it is on Github, you can get the code to see how this guy did it.
Well, since this guy figured out how to generate the secret hash,
malware will follow, so Microsoft's attempt to secure filetype and
protocol assignments was short-lived, but it remains with us in Win10 to
nuisance us. Since the solution was reverse engineered, Microsoft could
easily change their schema to prevent this workaround.

On 2020-07-28 07:25, VanguardLH wrote:
T wrote:

Several times now, I have had to go straight to the registry

Using the Default Apps wizard didn't work to change the default mail
handler? Or is it that the e-mail program didn't register itself as a
handler, so it is not listed in the Default Programs list?

No it is in the default apps dialog and it is registered


Whether you use the Default Apps wizard or edit the registry yourself
(or programmatically), not all filetypes for e-mail may get associated
to that e-mail program. Sometimes you have to go into Default Programs,
click "Set defaults by app", click the app, and click Manage. However,
that still might not catch all the filetypes you want to associate to a
handler, like protocols. Click the "Choose default apps by protocol".

Editing the registry may not always work. You might change the default
e-mail handler, but don't you also want .eml files associated with that
e-mail program? Some protected filetypes will have a UserChoice
registry key along with a hash string. If you use the Windows wizard to
define the handler for a filetype, Windows will generate the hash
string. You deleting the hash or trying to edit it will not generate a
valid value, so Windows will revert back to the default handler. For
example:

HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\FileExts\.avi\UserChoice

has VLC.avi, the filetype association for VLC (my choice of AVI player),
and has the UserChoice subkey under which are the ProgID and a hash that
Windows created. Me editing the registry to change the filetype
association won't work, because I won't know a correct hash to generate.
The same, for me, for:

HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\FileExts\.eml\UserChoice

where ProgID = eM Client.File.eml, and a Windows-generated hash value to
prevent tampering by registry editing -- whether that be you using
regedit.exe or a program (both use the registry API).

Since you're discussing e-mail, another protected entry is:

HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell \Associations\UrlAssociations\mailto\UserChoice

Yep, that has the UserChoice subkey with ProgID and Hash data items.
You can't generate a valid hash key. It's a protected choice.

Not all filetypes are protected via UserChoice and Hash, but enough are
that programmatic modification is a bitch under Windows 10. It's
Microsoft's scheme to thwart malicious change. I did encounter where my
e-mail client's own option "Make default" did not work. I had to use
the Windows-supplied Default Apps wizard to make the change for it to
stick. The programmatic method of changing the default mail handler
that worked in older versions of Windows may not work in Windows 10.
Same for editing the registry.

In Windows 10, programs are learning they have to present the Default
Apps wizard to make sure the default handler is changed to the user's
choice. However, even then the user may have to go into the app chosen
as the default handler to check all the filetypes are assigned to it.
After making eM Client my default e-mail program using their Default
Apps wizard, I still had to go to "Set defaults by app" to get some
filetypes changed to use eM Client as their handler.

You can try editing the registry to see if it sticks. Reboot Windows to
verify the change stuck. Else, you're stuck using the Windows wizards
to make changes since those know how to generate a valid hash value.

https://www.winhelponline.com/blog/s...ne-windows-10/

Looks like someone figured out a workaround; see:

http://kolbi.cz/blog/2017/10/25/setu...ions-per-user/
https://danysys.com/set-file-type-as...ternal-method/

Since it is on Github, you can get the code to see how this guy did it.
Well, since this guy figured out how to generate the secret hash,
malware will follow, so Microsoft's attempt to secure filetype and
protocol assignments was short-lived, but it remains with us in Win10 to
nuisance us. Since the solution was reverse engineered, Microsoft could
easily change their schema to prevent this workaround.


Next time I log into the customer I am going to check your
registry tips.

Thank you

-T

On 27/07/2020 18.15, VanguardLH wrote:
T wrote:

On 2020-07-26 19:44, VanguardLH wrote:
Maybe a MAPI-capable program was responsible for issuing the error
message, but it said "no email program associated", and nothing about a
failed MAPI call. The problem, and what you did, was to define the
default mail handler. Odd that Thunderbird wouldn't do that for you.

That was the jobs of Windows. When you set the default eMail
client, Windows is suppose to write that entry. I changed
it back and forth from other programs. Windows never
wrote out that entry

I find a lot of Windows 10 machine that seems to be "individuals"
lately. Just one machine acting weird.
"sfc /scannow" comes back perfect. So I tear my
hair out but eventually fix them.

Programs are no longer allowed to make some changes, like which is the
default e-mail client, filetype associations, and so on. Malware did
that, too, so Microsoft decided that some settings should only be
allowed by the user.

For the e-mail client that I use, I told them that the "Set as default"
option within the program would not work in Windows 10. The user could
click the button to think they made the change, but it never happened.
Eventually they wised up and had their program open the Default Programs
wizard in Windows 10. Their program couldn't make the change, so they
prompted the user by dumping them in the Default Programs wizard, and
the user had to make a manual change.

https://social.msdn.microsoft.com/Fo...elopmentissues

Blocking programmatic changes to defaults was a security measure to
thwart malware that would do the same thing. The user thought they were
starting a good program, but malware slid in a look-alike clone. Users
thought double-clicking a file to load into a default handler, but
malware had changed the filetype association. Not all such defaults or
filetypes are protected. I've yet to find a Microsoft publication to
specify which are protected to require user intervention and which are
the old way and left to any process to change to whatever they like.

The only way I see this improving is if Microsoft used certificates for
code signing, so good+signed programs could make the changes. Code
signing would take time and likely cost money. Alas, back then, malware
figured out how to usurp certs, and why some Windows updates were to
update certs to "Revoked" status. Microsoft requires Authenticode for
Microsoft-tested drivers (WHQL program), so maybe they'll have to extend
that to user-mode programs. However, the user should still get a choice
of whether they lock-down their computer by disallowing any unsigned
processes, or open it up to allowing any process to make any changes,
including malware.

No middle ground, allowing "some" user configured process to make changes?

--
Cheers, Carlos.

"Carlos E.R." wrote:

On 27/07/2020 18.15, VanguardLH wrote:
T wrote:

On 2020-07-26 19:44, VanguardLH wrote:
Maybe a MAPI-capable program was responsible for issuing the error
message, but it said "no email program associated", and nothing about a
failed MAPI call. The problem, and what you did, was to define the
default mail handler. Odd that Thunderbird wouldn't do that for you.

That was the jobs of Windows. When you set the default eMail
client, Windows is suppose to write that entry. I changed
it back and forth from other programs. Windows never
wrote out that entry

I find a lot of Windows 10 machine that seems to be "individuals"
lately. Just one machine acting weird.
"sfc /scannow" comes back perfect. So I tear my
hair out but eventually fix them.

Programs are no longer allowed to make some changes, like which is the
default e-mail client, filetype associations, and so on. Malware did
that, too, so Microsoft decided that some settings should only be
allowed by the user.

For the e-mail client that I use, I told them that the "Set as default"
option within the program would not work in Windows 10. The user could
click the button to think they made the change, but it never happened.
Eventually they wised up and had their program open the Default Programs
wizard in Windows 10. Their program couldn't make the change, so they
prompted the user by dumping them in the Default Programs wizard, and
the user had to make a manual change.

https://social.msdn.microsoft.com/Fo...elopmentissues

Blocking programmatic changes to defaults was a security measure to
thwart malware that would do the same thing. The user thought they were
starting a good program, but malware slid in a look-alike clone. Users
thought double-clicking a file to load into a default handler, but
malware had changed the filetype association. Not all such defaults or
filetypes are protected. I've yet to find a Microsoft publication to
specify which are protected to require user intervention and which are
the old way and left to any process to change to whatever they like.

The only way I see this improving is if Microsoft used certificates for
code signing, so good+signed programs could make the changes. Code
signing would take time and likely cost money. Alas, back then, malware
figured out how to usurp certs, and why some Windows updates were to
update certs to "Revoked" status. Microsoft requires Authenticode for
Microsoft-tested drivers (WHQL program), so maybe they'll have to extend
that to user-mode programs. However, the user should still get a choice
of whether they lock-down their computer by disallowing any unsigned
processes, or open it up to allowing any process to make any changes,
including malware.

No middle ground, allowing "some" user configured process to make changes?

Only if the user always gets an initial prompt whenever the program,
good or bad, want to make changes to filetype associations. Alas, we
already know users are just going to click through those prompts. And
is it the program them thought asked for permission, or some other
program intercepting or impostering a good program? And since when have
"good" programs always been behaved? No matter how much security is
deployed, common users assume they can do sysadmin jobs because, gee,
they can run an installer. They don't even read a Dummies book.