问题标签 [safefilehandle]

根据MSDN 文档FileStream.SafeFileHandle：

SafeFileHandle 属性自动刷新流并将当前流位置设置为 0。这允许使用此属性返回的 SafeFileHandle 移动文件或由另一个流重置流位置。

但是，我的测试似乎表明流位置没有改变。

考虑以下代码：

如果访问SafeFileHandle确实将当前流位置重置为 0，我预计第二个 WriteLine() 会打印 0。

我有其他测试，我实际使用SafeFileHandleWindows API ReadFile() 和 WriteFile() 方法，即使那样它似乎也没有改变文件指针。

我有一些使用的代码SafeFileHandle，所以流位置是否会改变对我来说非常重要！

我误解了文档，还是不正确？或者它有时会改变流的位置？（那将是一场噩梦！）

我正在尝试使用 kernel32.dll 的 CreateFile 方法为“C:”创建一个安全的文件句柄，该方法总是返回一个无效的句柄。

关于我在这里做错了什么有什么帮助吗？”C：

我在写入 FileStream 写入 SafeFileHandle 时遇到一些问题，该文件用于将数据写入 HID 设备。我将发布代码片段，因为它们出现在几个不同的对象中。

这是句柄创建代码：

返回的句柄是有效的。

然后是流：

流已成功创建，但 Position 和 Length 都返回 NotSupportedException （这是正常的）。

然后我发送消息：

这会立即返回以下异常消息：

这是堆栈跟踪的顶部：

提前致谢。

我有一个编写为 Windows 桌面应用程序的代码。我想将其转换为 windows storeapp。但是，我找不到 SafeFileHandle 的等价物。

这是代码。

Windows Storeapp 不支持 Microsoft.Win32.Safehandles dll。它给出错误“名称空间'Microsoft'中不存在类型或名称空间名称Win32（缺少程序集引用？）”

因此，SafeFilehandle 会给出类似“找不到类型或命名空间名称‘SafeFileHandle’”的错误。

你有什么建议吗？

谢谢。

在尝试使用 CreateFile() 创建处理程序时，即使以管理员身份执行应用程序，我也会收到以下错误消息：“系统找不到指定的文件。（来自 HRESULT 的异常：0x80070002）“：无。”</p>

以下是用于此任务的代码示例：

该路径指向 Windows Server 2003 中的矩阵打印机。

此应用程序在 Windows XP 中编译时可以正常运行，但在尝试在 Windows 7 中执行时，总是会出现上述错误。

我们最近遇到了一些可能与 CLR 的 GC 行为有关的问题。

我遇到的问题如下：

我们有一个用 C# 编写的长期运行的压力测试应用程序，它不断打开远程 SMB 文件共享（即 Azure 文件服务）上的文件句柄，并使用这些句柄执行文件系统操作，如读/写等。

通常我们会保持这些句柄打开很长一段时间，因为我们会重复使用它们。但是有时当我们尝试访问其中一些打开的句柄时，我们发现这些句柄已经关闭了。从 Process Monitor 捕获的跟踪日志（下面的一个示例）：

fltmgr.sys!FltpPerformPreCallbacks+0x324
fltmgr.sys!FltpPassThroughInternal+0x8c
fltmgr.sys!FltpPassThrough+0x169
fltmgr.sys!FltpDispatch+0x9e
ntoskrnl.exeIopCloseFile+0x146
ntoskrnl.exeObpDecrementHandleCount+0x9a
ntoskrnl.exeNtClose+0x3d9
ntoskrnl.exeKiSystemServiceCopyEnd+0x13
ntdll. dll!ZwClose+0xa
KERNELBASE.dll!CloseHandle+0x17
mscorlib.ni.dll!mscorlib.ni.dll!+0x566038
clr.dll!CallDescrWorkerInternal+0x83
clr.dll!CallDescrWorkerWithHandler+0x4a
clr.dll!DispatchCallSimple+0x60
clr.dll !SafeHandle::RunReleaseMethod+0x69
clr.dll!SafeHandle::Release+0x152
clr.dll!SafeHandle::Dispose+0x5a
clr.dll!SafeHandle::DisposeNative+0x9b
mscorlib.ni.dll!mscorlib.ni.dll!+0x48d9d1
mscorlib.ni.dll!mscorlib.ni.dll!+0x504b83
clr.dll!FastCallFinalizeWorker+0x6
clr.dll!FastCallFinalize +0x55
clr.dll!MethodTable::CallFinalizer+0xac
clr.dll!WKS::CallFinalizer+0x61
clr.dll!WKS::DoOneFinalization+0x92
clr.dll!WKS::FinalizeAllObjects+0x8f
clr.dll!WKS::FinalizeAllObjects_Wrapper +0x18
clr.dll!ManagedThreadBase_DispatchInner+0x2d
clr.dll!ManagedThreadBase_DispatchMiddle+0x6c
clr.dll!ManagedThreadBase_DispatchOuter+0x75
clr.dll!ManagedThreadBase_DispatchInCorrectAD+0x15
clr.dll!Thread::DoADCallBack+0xff
clr.dll!ManagedThreadBase_DispatchInner+0x
clr.dll!WKS::DoOneFinalization+0x145
clr.dll!WKS::FinalizeAllObjects+0x8f
clr.dll!WKS::GCHeap::FinalizerThreadWorker+0xa1
clr.dll!ManagedThreadBase_DispatchInner+0x2d
clr.dll!ManagedThreadBase_DispatchMiddle+0x6c
clr.dll !ManagedThreadBase_DispatchOuter+0x75
clr.dll!WKS::GCHeap::FinalizerThreadStart+0xd7
clr.dll!Thread::intermediateThreadProc+0x7d
KERNEL32.dll!BaseThreadInitThunk+0x1a
ntdll.dll!RtlUserThreadStart+0x1d

似乎句柄在 CLR GC Finalizer 线程中关闭。然而，我们的句柄以下列不应该被 GC 的模式打开：

我们使用 P/Invoke 打开一个文件句柄并获取一个 SafeFileHandle 并使用该 SafeFileHandle 构造一个 FileStream，我们将 FileStream 对象保存在另一个定义如下的对象中：

}

我们使用的 P/Invoke：

SafeFileHandle fileHandle = Win32FileIO.CreateFile(fullFilePath, win32FileAccess, win32FileShare, IntPtr.Zero, win32FileMode, win32FileAttr, IntPtr.Zero);

FileStream fileStream = new FileStream(fileHandle, fileAccess, Constants.XSMBFileSectorSize);

我们可以确定的一件事是，在压力测试应用程序的整个生命周期中，我们肯定会保留对 ScteFileHandle 对象的引用，因此它永远不会被 GC 清理。但是，我们确实观察到在 ScteFileHandle 的 FileStream 中引用的 SafeHandle 已在 CLR GC 线程中完成，如粘贴在上面的跟踪日志中。

所以我想知道是什么导致 SafeFileHandle 被 GC'ed 以及是否有任何方法可以避免这种情况？我不熟悉 CLR GC 行为，但从我的角度来看，SafeFileHandle 不应该被 GC 处理。

非常感谢任何指针或见解！如果您需要诊断此问题的任何其他详细信息，请告诉我:)

我正在尝试使用 CloseHandle 释放 USB 接口的句柄。我得到的例外是：

System.Runtime.InteropServices.SEHException (0x80004005)：外部组件已引发异常。在 Device.Net.APICalls.CloseHandle(SafeFileHandle hObject) 在 Usb.Net.Windows.UsbInterface.Dispose() 在 C:\GitRepos\Device.Net\src\Usb.Net\Windows\UsbInterface.cs:第 23 行在
Usb .Net.Windows.WindowsUsbDevice.Dispose() 在 C:\GitRepos\Device.Net\src\Usb.Net\Windows\WindowsUsbDevice.cs:131 行

我正在尝试在我班级的 Dispose 方法中执行此操作。

编辑背景：我试图这样做的原因是我的代码在我第二次运行它时崩溃了。根据这篇文章，我必须在我用 CreateFile 创建的设备的句柄上调用 CloseHandle。无论如何，这是在我的代码中完成的，因为设备的句柄正在被释放，因为它是一个 SafeFileHandle。但是，有人告诉我，我需要在接口的句柄上调用 CloseHandle。我不知道这是否属实。我试图这样做以排除不调用 CloseHandle 是导致该错误的原因的可能性。根据其他评论和研究，我现在认为这是一个错误，调用 WinUsb_Free 就足够了。这个对吗？

Hans Passant 在下面的回答是告诉我删除对 CloseHandle 的调用，但正如我在评论中指出的那样，原始代码（在 master 中）从来没有首先调用 CloseHandle。当然，删除呼叫会起作用，但这不是问题。下面的问题是：用WinUSB API发布USB接口的流程是什么？. 仅仅是调用 WinUsb_Free 吗？这就是我所拥有的所有信息让我相信的。

这是我问这个问题之前的原始处置方法。它没有对 CloseHandle 的调用。

从 WindowsUsbInterface（https://github.com/MelbourneDeveloper/Device.Net/blob/9ebc122a2755dda2824c6eda961d092f2f6e83b5/src/Usb.Net/Windows/WindowsUsbDevice.cs#L122）：

来自 UsbInterface（https://github.com/MelbourneDeveloper/Device.Net/blob/9ebc122a2755dda2824c6eda961d092f2f6e83b5/src/Usb.Net/Windows/UsbInterface.cs#L18）：

API 调用定义（https://github.com/MelbourneDeveloper/Device.Net/blob/CloseHandle/src/Device.Net/Windows/APICalls.cs）：

我也尝试过简单地处理句柄，因为它是 SafeFileHandle，但 SafeFileHandle 的 Dispose 方法给了我相同的错误消息。这向我表明 SafeFileHandle 的 Dispose 方法可能也在调用 CloseHandle，并且正在发生同样的问题。

其他人提到我应该使用 IntPtr 而不是 SafeFileHandle。所以，我尝试在 CloseHandle 的界面上使用 IntPtr，但问题是一样的：

这是WinUsb_Initialize的定义

使用 WinUSB API 发布 USB 接口的流程是什么？在 C# 中我需要做些不同的事情吗？为什么会出现这个错误？

我正在尝试在脚本中使用文件句柄DATA，将值分配给变量，当它打印时它只打印和空字符串。

虽然我还在学习 System.IO，在File Streamclass 的构造函数中，我发现有名为 类型的重载构造函数SafeFileHandle，我尝试在互联网和 MSDN Documention 上搜索，但我什么都看不懂，我发现甚至更 陌生的词，比如IntPtr，谁能给我解释一下？

有人可以解释一下吗，或者有没有好的网站可以学习..？

我想知道 FileStream 关​​闭后是否可以重新打开句柄？

这是我的代码

我在声明 fs2 时收到错误“句柄已关闭”。

谢谢 ：）