DllImport调用WNetAddConnection2失败，GetLastError返回12007？

Question

DllImport调用`WNetAddConnection2`失败且`GetLastError()`返回12007（ERROR_INTERNET_NAME_NOT_RESOLVED），本质并非网络连接错误，而是**Windows映射网络驱动器时对目标UNC路径的解析失败**。常见原因包括：① 传入的`lpRemoteName`参数格式不合法（如缺少`\\server\share`双反斜杠前缀、含尾部反斜杠或空格）；② 目标服务器名无法通过NetBIOS或DNS解析（尤其在域环境或启用了LLMNR/IPv6的场景下）；③ 调用线程未正确初始化COM（虽非必需，但部分系统组件依赖）；④ `NETRESOURCE`结构体字段未严格按文档要求填充（如`dwType = RESOURCETYPE_DISK`、`lpLocalName`为null或合法盘符、`dwScope`与使用场景不匹配）。特别注意：12007是WinInet错误码，被错误映射至此API——这提示底层可能误用了HTTP相关解析逻辑，实则应优先排查UNC可达性（`ping -a server`、`net view \\server`）及防火墙/Server服务状态。建议启用`WNetUseConnection`替代，并确保P/Invoke签名中字符串编码（`CharSet = CharSet.Auto`）与结构体内存布局（`[StructLayout(LayoutKind.Sequential)]`）完全合规。

Answer 1

```html

一、现象定位：错误码12007的语义陷阱

ERROR_INTERNET_NAME_NOT_RESOLVED（12007）本属WinINet.dll错误域，却在调用WNetAddConnection2时意外返回——这是Windows网络API层错误码映射失当的典型信号。它并非指示HTTP/DNS解析失败，而是底层SMB/Workstation服务在尝试解析UNC路径\\server\share时，因名称解析链路中断而“借用”了WinINet的通用错误码。此现象在Windows 10/11及Server 2016+中高频复现，尤其当系统启用了LLMNR、Multicast DNS或IPv6链路本地地址协商时更为隐蔽。

二、根因分层分析：从表象到内核

• UNC语法层：缺失双反斜杠前缀（如传入"server\share"）、尾部冗余反斜杠（"\\server\share\\"）、路径含不可见Unicode空格（U+00A0）或制表符；
• 网络协议层：NetBIOS over TCP/IP未启用、DNS后缀搜索列表缺失、域控制器SRV记录异常、防火墙阻断UDP 137/138（NetBIOS Name Service）；
• 运行时环境层：COM未初始化（CoInitializeEx(null, COINIT_APARTMENTTHREADED)缺失），导致某些Windows Shell扩展组件无法参与UNC解析；
• 结构体契约层：NETRESOURCE中dwScope设为CONNECTION_SCOPE_GLOBAL但目标服务器不在全局可见域，或lpLocalName传入非法盘符（如"Z:"未加冒号或"A:\\"含尾斜杠）。

三、诊断流程图：结构化排错路径

flowchart TD A[重现问题] --> B{UNC格式校验} B -->|合法| C[执行 ping -a server] B -->|非法| D[修正为\\\\server\\share] C --> E{是否解析出主机名？} E -->|否| F[检查DNS/NetBIOS配置] E -->|是| G[执行 net view \\\\server] G --> H{是否列出共享？} H -->|否| I[验证Server服务状态
sc query LanmanServer] H -->|是| J[检查P/Invoke签名与内存布局]

四、关键代码合规性对照表

要素	正确实践	常见错误
DllImport签名	[DllImport("mpr.dll", CharSet = CharSet.Auto)]	CharSet = CharSet.Ansi（导致Unicode UNC截断）
NETRESOURCE布局	[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)]	遗漏CharSet或使用LayoutKind.Explicit
dwType赋值	RESOURCETYPE_DISK（0x01）	误设为RESOURCETYPE_PRINT（0x02）

五、工程级解决方案集

1. 优先采用WNetUseConnection替代WNetAddConnection2：其对UNC解析更鲁棒，且支持CONNECT_UPDATE_PROFILE持久化；
2. UNC预检函数：bool IsValidUncPath(string unc) => unc?.StartsWith(@"\\", StringComparison.Ordinal) == true && !unc.EndsWith("\\", StringComparison.Ordinal);
3. 强制DNS解析兜底：Dns.GetHostEntry("server") + new IPAddress(...).ToString() 构造\\192.168.1.100\share；
4. 线程级COM初始化封装：using var _ = new ComInitializer(); // 实现IDisposable的CoInitializeEx封装；
5. 启用详细日志：netsh trace start scenario=InternetClient capture=yes report=yes，事后用netsh trace stop分析SMB名称解析环节。

六、高级调试技巧：穿透系统抽象层

当常规手段失效时，启用ProcMon（Process Monitor）捕获WNetAddConnection2调用过程中的所有RegQueryValue与TCPIP.SYS相关NetworkConnect事件；同时使用Wireshark过滤nbns || dns || smb2协议栈，观察客户端是否发出NetBIOS Name Query Request或DNS A/AAAA查询，以及是否收到响应——这能直接验证是客户端解析失败，还是服务端未响应。

七、跨版本兼容性警示

Windows 11 22H2+默认禁用NetBIOS over TCP/IP（除非显式启用），且LLMNR响应被策略限制；若目标环境为Azure AD Joined设备，需额外验证Workstation服务是否启用EnableLlmnr注册表项（HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters），否则\\server将永远无法解析。

```