Windows 10通知设置中部分发送通知的应用未显示在「获取来自这些发送者的通知」列表的原因排查

最近不少用户碰到一个头疼的问题：有些明明能在操作中心弹出通知的应用，却死活出现在「获取来自这些发送者的通知」列表里，没法直接在系统设置里管理它们的通知权限。结合实际测试和对Windows通知机制的拆解，咱们来一步步梳理可能的原因和背后的逻辑。

Windows 10通知数据的存储变迁 #

• 在1607补丁之前，通知相关的配置数据是存在Windows注册表的AppDB字段中的
• 1607补丁之后，核心的通知数据迁移到了SQLite数据库文件：c:\Users\%USERNAME%\AppData\Local\Microsoft\Windows\Notifications\wpndatabase.db，这个数据库里存着最近3天的通知记录、应用通知设置，以及所有曾经发送过通知的应用列表

测试发现的关键矛盾：数据库不是唯一数据源 #

我特意做了一组测试来验证wpndatabase.db是不是「获取来自这些发送者的通知」列表的唯一依据：

1. 先在设置里禁用Lightshot的通知权限
2. 停止WPNUserService服务，删除wpndatabase.db文件，再重启服务
3. 此时打开「获取来自这些发送者的通知」，列表是空的
4. 用Lightshot截一张图触发通知，结果通知并没有弹出（说明权限还是禁用状态）
5. 再回到设置列表，Lightshot居然重新出现了，而且依然是禁用状态！

这就说明，wpndatabase.db并不是通知设置的最终来源，系统里还有其他地方存储着应用的通知权限配置。

注册表的遗留配置影响 #

后续深入排查发现，注册表路径Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\<Appname>下的Enabled DWORD（32位）值，会直接影响wpndatabase.db中HandlerSettings表的s:toast字段：

• 当把Enabled设为0时，要么在应用下次发送通知时，要么在重启WPNUserService服务后，wpndatabase.db里的s:toast值会被同步设为0（对应通知禁用）
• 但反过来，如果把Enabled改回1或者直接删除这个值，却不会让s:toast同步变回1，看起来这是个遗留的配置项——WPN服务只会读取它的禁用状态，不会处理启用操作

为什么有些应用不在设置列表里？ #

结合上面的机制分析，大概率是这几个原因：

• 应用未完成正规通知注册：像你提到的someapp、mywebapp这类第三方应用，可能用了非标准的通知推送方式，没有在系统中完成正规的通知权限注册流程。这就导致系统设置界面无法识别它们的存在，只能通过通知 toast 临时关闭权限，但一旦清理数据库或重启服务，就没法在设置里找到它们了
• 注册表遗留配置冲突：如果这些应用曾经被手动通过注册表设置过Enabled=0，后续即使恢复了通知推送，WPN服务可能依然只读取注册表的遗留禁用状态，不会把应用重新加入设置列表
• 数据库缓存期限限制：wpndatabase.db只保留最近3天的通知数据，如果应用超过3天没发过通知，可能会从设置列表中被移除；但如果之后又发通知，正常情况下应该重新出现——如果没出现，那大概率是应用自身的注册有问题
• WPN服务同步异常：WPNUserService负责同步通知设置和应用列表到系统设置界面，如果服务运行异常或者同步逻辑存在bug，也可能导致部分应用的信息无法被正确同步显示

备注：内容来源于stack exchange，提问作者setec