在Windows中重新启动时访问相同的资源
我会在系统关闭或服务关闭之前在文件/内存中写入一些内容。 在系统下次重新启动时，在文件系统加载之前是否可以访问磁盘上的相同文件或相同内存？ 实际需求是这样的，我们有一个位于卷级驱动程序和文件系统驱动程序之间的驱动程序......在驱动程序代码的这一部分中，我想访问一些内存或文件。
谢谢& 问候，
卡尔文
I will write some thing in a file/memory just before system shutdown or a service shutdown. In the next restart of system, Is it possible to access same file or same memory on the disk, before filesystem loads? Actual requirement is like this, we have a driver that sits between volume level drivers and filesystem driver...in that part of the driver code, I want to access some memory or file.
Thanks & Regards,
calvin
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里合乎逻辑的事情是，如果它不太大，则将其读/写到注册表中。 您有什么理由不想使用注册表吗？
如果您需要访问大数据并且正在编写卷或设备过滤器并且不能依赖内核中的 ZwOpen/Read/Write/Close 函数，则一种方法是在用户模式下创建文件，获取其设备名称和簇链并将它们存储在注册表中。 下次启动时，您可以从注册表获取设备和集群，并对它们进行直接 I/O。
The logical thing here is to read/write this into the registry if it is not too big. Is there a reason you do not want to use the registry?
If you need to access large data and you are writing a volume or device filter and cannot rely on ZwOpen/Read/Write/Close functions in the kernel an approach would be to create the file in user mode, get its device name and cluster chain and store them in the registry. On the next boot, you can get the device and clusters from registry, and do direct I/O on them.
由于您想在文件系统加载之前访问它，因此我的第一个想法是在文件系统外部的硬盘驱动器上分配和使用一块存储空间。 您可以在驱动器上创建隐藏的小型分区，并使用低级 I/O 命令来读取和写入数据。
这是嵌入式系统领域的一项常见任务，我们通常通过在系统中添加某种非易失性存储设备（闪存、电池供电的 DRAM 等）并读写该设备来实现它。 由于您可能无法像嵌入式开发人员一样对可用硬件进行相同级别的控制，因此我能想到的最接近的模拟是在物理磁盘上保留一块空间，您可以从中读取数据，而无需安装为一个文件系统。 专用的迷你分区可能效果最好，因为如果您知道它的大小，您可以将其视为一个大的原始访问缓冲区，并且可以避免与文件名、文件系统等有关的麻烦。
Since you want to access this before the filesystem loads, my first thought is to allocate and use a block of storage space on the hard drive outside of the filesystem. You can create a hidden mini-partition on the drive and use low-level I/O commands to read and write your data.
This is a common task in the world of embedded systems, and we often implement it by adding some sort of non-volatile memory device into the system (flash, battery-backed DRAM, etc) and reading and writing to that device. Since you likely don't have the same level of control over the available hardware as embedded developers do, the closest analogue I can think of would be to reserve a chunk of space on a physical disk that you can read from without having to mount as a filesystem. A dedicated mini-partition might work the best because if you know the size of it, you can treat it as one big raw-access buffer and can avoid having to hassle with filenames, filesystems, etc.