VB.Net编译后消息队列调用CreateFile失败（错误998）求助

错误998（ERROR_NOACCESS）本质是无效内存访问，结合你描述的「源码运行正常、编译后仅消息队列调用失败」的差异，核心问题大概率出在线程上下文、托管内存管理、编译优化这几个维度，下面给你一步步拆解排查方向和修复建议：

1. 先确认Win32 API声明的正确性（尤其是64位兼容性） #

VB.Net默认的Any CPU编译模式下，Debug和Release可能存在位数差异，而Win32 API的参数类型如果不匹配，很容易导致内存访问错误。请核对你的API声明是否符合以下规范：

' 正确的CreateFile声明（适配32/64位，CharSet指定Unicode）
<DllImport("kernel32.dll", SetLastError:=True, CharSet:=CharSet.Unicode)>
Private Shared Function CreateFile(
    lpFileName As String,
    dwDesiredAccess As UInteger,
    dwShareMode As UInteger,
    lpSecurityAttributes As IntPtr,
    dwCreationDisposition As UInteger,
    dwFlagsAndAttributes As UInteger,
    hTemplateFile As IntPtr
) As IntPtr
End Function

' WriteFile和CloseHandle同理，注意参数类型用UInteger对应Win32的DWORD
<DllImport("kernel32.dll", SetLastError:=True)>
Private Shared Function WriteFile(
    hFile As IntPtr,
    lpBuffer As IntPtr,
    nNumberOfBytesToWrite As UInteger,
    <Out> ByRef lpNumberOfBytesWritten As UInteger,
    lpOverlapped As IntPtr
) As Boolean
End Function

<DllImport("kernel32.dll", SetLastError:=True)>
Private Shared Function CloseHandle(hObject As IntPtr) As Boolean
End Function

重点注意：

• 用UInteger而非Integer传递DWORD类型参数（比如dwDesiredAccess），64位环境下Integer会导致内存对齐错误
• 指定CharSet.Unicode确保字符串传递正确，避免ANSI/Unicode编码不匹配导致的无效指针

2. 修复托管内存的GC回收问题（Release优化坑） #

Release模式下VB.Net会启用代码优化，可能导致托管字符串/变量被GC提前回收，而Win32 API调用时还在使用这些内存，直接触发错误998。解决办法：

显式固定托管字符串 #

调用CreateFile前，手动固定文件路径的内存，避免GC移动：

Dim filePath As String = "你的文件绝对路径"
Dim filePathPtr As IntPtr = Marshal.StringToHGlobalUni(filePath)
Try
    Dim hFile As IntPtr = CreateFile(filePathPtr, GENERIC_WRITE, 0, IntPtr.Zero, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, IntPtr.Zero)
    If hFile = INVALID_HANDLE_VALUE Then
        Dim errCode As Integer = Marshal.GetLastWin32Error()
        ' 记录错误日志
    Else
        ' 执行WriteFile逻辑
        Dim bytesWritten As UInteger
        WriteFile(hFile, bufferPtr, bufferSize, bytesWritten, IntPtr.Zero)
        ' 务必关闭句柄
        CloseHandle(hFile)
    End If
Finally
    ' 释放固定的内存
    Marshal.FreeHGlobal(filePathPtr)
End Try

用GC.KeepAlive阻止提前回收 #

如果不想手动固定内存，也可以在API调用后添加GC.KeepAlive，告诉GC不要回收相关变量：

Call CreateFile(filePath, ...)
GC.KeepAlive(filePath) ' 确保filePath在API调用完成后才被回收

3. 检查消息队列线程的公寓状态 #

WinForms是单线程公寓（STA）模型，而默认的消息队列线程（比如System.Messaging.MessageQueue的接收线程）可能是多线程公寓（MTA），部分Win32 API在MTA线程中调用会引发内存访问问题。

如果是自定义的消息处理线程，手动设置STA状态：

Dim queueWorkerThread As New Thread(AddressOf ProcessQueueMessages)
queueWorkerThread.SetApartmentState(ApartmentState.STA) ' 强制设置为STA
queueWorkerThread.Start()

4. 确保句柄资源的正确释放 #

虽然错误是998，但如果首次调用CreateFile后没有关闭句柄，会导致句柄泄漏，后续调用可能因资源耗尽触发内存访问错误。务必在所有分支（成功/失败）中调用CloseHandle：

Dim hFile As IntPtr = CreateFile(...)
If hFile <> INVALID_HANDLE_VALUE Then
    Try
        ' 写入文件逻辑
    Finally
        CloseHandle(hFile) ' 不管写入成功与否都关闭句柄
    End Try
End If

5. 排查编译设置的差异 #

对比Debug和Release的项目编译设置：

• 关闭Release模式的「优化代码」选项（项目属性 → 编译 → 优化代码），如果关闭后问题消失，说明是优化导致的变量提前回收，用上面的GC.KeepAlive或内存固定方案解决
• 确认Debug和Release的「目标平台」一致（比如都是x86或Any CPU），避免位数差异引发的API调用错误

内容的提问来源于stack exchange，提问作者B. Price