关于nul报错的底层原理理解

目录

问题描述

（一）selenium初始化浏览器报错

（二）adb启动报错

临时解决方式: 命令行执行 adb nodaemon server

深入了解语句作用

问题解决方法

（一）系统文件检查

1. 验证系统是否能访问nul设备

2.检查环境变量或脚本冲突

3.禁用安全软件：临时关闭杀毒软件或防火墙（如360、火绒等），测试是否冲突。

4.验证注册表配置的准确性

（二）修复方式

1.运行系统文件检查

2.深度修复系统文件

3.直接替换null.sys文件【需要较高权限】

问题描述

电脑一直环境存在问题，基本是关于nul系统文件找不到，会遇到如下几种情况【后续遇到了会继续补充】：

（一）selenium初始化浏览器报错

        继续跟到底层库的部分：

        在读取os.devnull时报错，继续了解os.devnull是什么

        os.devnull是一个特殊的文件名，表示一个空设备文件。在不同的操作系统中，它的路径不同：在Unix-like系统（如Linux和macOS）中，路径通常是/dev/null；在Windows系统中，路径是NUL。‌os.devnull的主要作用是丢弃所有写入其中的数据‌，常用于重定向标准输出或错误输出到这个设备，从而避免输出内容显示在控制台或日志文件中‌。

1‌.重定向标准输出‌：在执行某些命令或脚本时，如果不需要输出结果，可以将标准输出重定向到os.devnull。例如：

with open(os.devnull, "w") as devnull:
    with contextlib.redirect_stdout(devnull):
        print("Hello, World!")

        这段代码会打印“Hello, World!”但不会在控制台显示任何输出‌1。

2‌.重定向错误输出‌：类似地，可以将错误输出重定向到os.devnull，以避免错误信息干扰其他日志或输出。例如：

with open(os.devnull, "w") as devnull:
    with contextlib.redirect_stderr(devnull):
        raise Exception("This will not be shown on the console.")

（二）adb启动报错

临时解决方式: 命令行执行 adb nodaemon server

在执行命令行之后另启一个adb调用adb devices，正常显示连接设备

深入了解语句作用

继续了解为什么执行adb nodaemon server之后adb可以正常调用

1. ADB 的工作机制

ADB（Android Debug Bridge）分为两部分：

• ADB 客户端：你执行的 adb 命令（如 adb devices）。

• ADB 服务端：一个后台进程（adb-server），负责管理与设备的通信。

默认情况下，当你执行任何 adb 命令时：

1. 客户端会检查服务端是否已启动。

2. 如果服务端未运行，客户端会自动启动服务端（以守护进程形式在后台运行）。

3. 服务端启动后，客户端与服务端通信，完成命令的执行。

2. nul 设备的作用

在 Windows 系统中，nul 是一个特殊的虚拟设备文件，用于丢弃所有写入的数据（类似于 Linux 中的 /dev/null）。ADB 服务端在启动时，可能会尝试将某些日志或输出重定向到 nul 设备，以避免在终端中显示无关信息。

如果系统无法访问 nul 设备（例如由于注册表损坏、权限问题或驱动异常），ADB 服务端的启动过程会失败，从而导致 adb 命令无法正常运行。

3. adb nodaemon server 的作用

adb nodaemon server 是手动启动 ADB 服务端，并以 非守护进程模式（前台运行） 运行的命令。它的行为与默认的自动启动方式有以下不同：

1. 不依赖 nul 设备：

   • 在非守护进程模式下，服务端的日志和输出会直接打印到当前终端，而不是重定向到 nul 设备。

   • 因此，即使系统无法访问 nul 设备，服务端仍能正常启动。

2. 绕过自动启动逻辑：

   • 默认情况下，ADB 客户端会自动尝试启动服务端，但这一过程可能会因 nul 设备问题而失败。

   • 通过手动运行 adb nodaemon server，你绕过了客户端的自动启动逻辑，直接启动了服务端。

问题解决方法

目前我尝试了一些方法，部分没起作用，还没完全解决，正在还解决中。。。后续更新

（一）系统文件检查

1. 验证系统是否能访问nul设备

在命令行中运行以下命令，检查是否能正常写入nul：

echo test > nul

我的运行结果是找不到指定文件。。

2.检查环境变量或脚本冲突

• 检查环境变量：
  确保没有自定义环境变量将nul指向其他路径。

• 临时清除环境变量测试：
  在命令提示符中运行：

set TEMP=
set TMP=

然后再次尝试ADB命令。

尝试依然没用。。

3.禁用安全软件：
临时关闭杀毒软件或防火墙（如360、火绒等），测试是否冲突。

还未尝试，试下再记录

4.验证注册表配置的准确性

虽然注册表的 DOS Devices 路径下存在 nul 项，仍需确保其配置完全正确：

1. 打开注册表编辑器 (regedit)。

2. 导航到路径：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices

3. 检查 nul 项的 类型 和 数值数据：

   • 类型：必须是 REG_SZ（字符串值）。

   • 数值数据：必须为 \Device\Null（注意大小写和斜杠方向）。

   • 错误示例：若数值为 \??\Null 或其他路径，会导致访问失败。

4. 若发现错误，右键修改 nul 项的数值数据，重启系统后测试。

（二）修复方式

1.运行系统文件检查

以管理员身份打开命令提示符：

sfc /scannow

1. 扫描完成后重启系统，再次尝试ADB命令。

2.深度修复系统文件

sfc /scannow 可能无法修复所有问题，需结合 DISM 工具

以管理员身份运行命令提示符：

DISM /Online /Cleanup-Image /RestoreHealth

• 此操作会从 Windows 更新服务器下载健康文件替换损坏部分。

• 完成后重启系统，再次运行 sfc /scannow。

3.直接替换null.sys文件【需要较高权限】

直接找一个相同系统的电脑拷过来，该方法还没试，后续补充

C:\Windows\System32\drivers\null.sys