Jump to content











Photo
- - - - -

There are lots of errors in WIN's LOG!

debug

  • Please log in to reply
17 replies to this topic

#1 Jjimmy

Jjimmy
  • Members
  • 2 posts
  •  
    China

Posted 20 January 2016 - 10:32 AM

I used the imdisk to create a disk in physical memory with "imdisk -a -s 500M -o awe -m Z: -p "/FS:NTFS /Q /Y" " command, and then detached it with "imdisk -D -m Z:\" command. It works seems right.

But when i use command "imdisk -l", it shows:

\Device\ImDisk1
\Device\ImDisk0
besides, there are lots of errors in WIN's system LOG. The xml file is FOLLOW:
 
- <System>
  <Provider Name="Microsoft-Windows-Ntfs" Guid="{3FF37A1C-A68D-4D6E-8C9B-F79E8B16C482}" />
  <EventID>140</EventID>
  <Version>0</Version>
  <Level>3</Level>
  <Task>0</Task>
  <Opcode>0</Opcode>
  <Keywords>0x8000000000000008</Keywords>
  <TimeCreated SystemTime="2016-01-20T10:18:47.555983700Z" />
  <EventRecordID>9932</EventRecordID>
  <Correlation />
  <Execution ProcessID="4" ThreadID="14980" />
  <Channel>System</Channel>
  <Computer>wiselile</Computer>
  <Security UserID="S-1-5-18" />
  </System>
- <EventData>
  <Data Name="VolumeId">??</Data>
  <Data Name="DeviceName">\Device\ImDisk0</Data>
  <Data Name="Error">0xc00002b6</Data>
  </EventData>
  </Event>
 
And my computer is win10 ,the vision of imdisk is 2.0.9
 


#2 Jjimmy

Jjimmy
  • Members
  • 2 posts
  •  
    China

Posted 20 January 2016 - 11:23 AM

The problem solved by reboot



#3 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1416 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 20 January 2016 - 09:22 PM

When you use -D or -R to remove an ImDisk virtual disk instead of using -d, this is expected. This is because the filesystem is not safely dismounted and the disk device will be removed before the filesystem driver might have finished all operations on the disk. Therefore, only use -D or -R in emergency, otherwise use -d instead!



#4 v77

v77

    Silver Member

  • Team Reboot
  • 570 posts
  •  
    France

Posted 21 January 2016 - 12:36 PM

When you use -D or -R to remove an ImDisk virtual disk instead of using -d, this is expected. This is because the filesystem is not safely dismounted and the disk device will be removed before the filesystem driver might have finished all operations on the disk. Therefore, only use -D or -R in emergency, otherwise use -d instead!

 

Not so obvious for the -D switch... With it, the file system is supposed to be properly dismounted, thanks to the FSCTL_DISMOUNT_VOLUME control code, no matter there are open handles or not.

However, I tried the commands of the first message on Windows 10, and the first time, I too, have seen an error of NTFS in the event log. And this time, the time to notify applications was pretty long... (something like 30 seconds) This behavior does not occur every time, this is just one more bug of Windows 10.



#5 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15104 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 January 2016 - 01:22 PM

More loosely, wouldn't it be possible to issue some kind of "flushing" command before dismounting the volume? :unsure:

 

Something more or less along the lines of what "removedrive" can do for USB drives:

http://www.uwe-siebe...tml#RemoveDrive

or FFB FlushFileBuffers (same page above) see also:

https://msdn.microso...9(v=vs.85).aspx

 

:duff:

Wonko



#6 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1416 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 21 January 2016 - 01:29 PM

Not so obvious for the -D switch... With it, the file system is supposed to be properly dismounted, thanks to the FSCTL_DISMOUNT_VOLUME control code, no matter there are open handles or not.

However, I tried the commands of the first message on Windows 10, and the first time, I too, have seen an error of NTFS in the event log. And this time, the time to notify applications was pretty long... (something like 30 seconds) This behavior does not occur every time, this is just one more bug of Windows 10.

 

Actually, there have been examples since at least Windows 2000, though. The only real difference that I have seen seems to be that NTFS driver in Windows 10 has a bit more logging turned on by default. The entire problem with "left-behind" device objects that keep showing with "imdisk -l" after a -D removal is connected to the same core problem and that problem has been around for quite a while.

 

More loosely, wouldn't it be possible to issue some kind of "flushing" command before dismounting the volume? :unsure:

 

Something more or less along the lines of what "removedrive" can do for USB drives:

http://www.uwe-siebe...tml#RemoveDrive

 

That thing uses plug-and-play features that are not available for ancient things like ImDisk ;)



#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15104 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 January 2016 - 01:36 PM

That thing uses plug-and-play features that are not available for ancient things like ImDisk  ;)

Sure :), but some similar mechanism should be doable, does the FFB (the API call, not necessarily Uwe Siebers's little tool) work on IMDISK volumes?

 

:duff:

Wonko



#8 v77

v77

    Silver Member

  • Team Reboot
  • 570 posts
  •  
    France

Posted 21 January 2016 - 03:31 PM

More loosely, wouldn't it be possible to issue some kind of "flushing" command before dismounting the volume? :unsure:

 

Did you never see the "Flushing file buffers..." message when you dismount a volume with imdisk.exe?

This message is displayed while FlushFileBuffers is working.



#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15104 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 January 2016 - 03:45 PM

Did you never see the "Flushing file buffers..." message when you dismount a volume with imdisk.exe?

This message is displayed while FlushFileBuffers is working.

Well, should we assume that the issue with -D you just reported is an "act of God" or simply put the blame on the stupid Windows 10 or see if something can be done to avoid it? :dubbio:

 

Another semi-random idea :w00t: :ph34r: what happens if one runs a format /q on the volume before attempting to dismount it?

(on the assumption that the error in the log is somehow connected to file or *whatever* still in use and the dismounting command *somehow* missing it) :unsure:

 

:duff:

 

Wonko



#10 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1416 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 21 January 2016 - 10:06 PM

Well, should we assume that the issue with -D you just reported is an "act of God" or simply put the blame on the stupid Windows 10 or see if something can be done to avoid it? :dubbio:
 
Another semi-random idea :w00t: :ph34r: what happens if one runs a format /q on the volume before attempting to dismount it?
(on the assumption that the error in the log is somehow connected to file or *whatever* still in use and the dismounting command *somehow* missing it) :unsure:


You mean format /x (or similar options to for instance chkdsk) to force dismount? That works - but has occasionally about the same trouble with some filesystem drivers logging errors for non-pnp disks if there were references open to a few specific directories on the volume.
 

There have been a few discussions about this in various driver development forums. It generally came up as an issue when people wrote disk volume filter drivers for NT 4 and earlier and wanted to be able to detach their filters without reboot. It is tricky, because the filesystem driver attached to a device object created by the filter driver and needed that reference to be valid as long as the filesystem was mounted. Then, because filesystem drivers could not always detach properly, such projects frequently ran into trouble when the filter driver should unload.

 

It was partially resolved when plug-and-play was introduced in Windows 2000 and "device removal relations" were introduced. Pnp came with a clear and standardized concept for telling devices that they were about to be removed (or had been surprise-removed) and automatically call all dependent devices to remove themselves at the same time. But snce many filter drivers continued to be developed with the old technology for a long time, the problem remained in many cases. (In the case of ImDisk the problem occurs with the lowest-level device object itself and not a filter driver.)

 



#11 xyBogli

xyBogli

    Newbie

  • Members
  • 29 posts

Posted 24 January 2016 - 10:18 AM

Any one here has Dropbox issue on windows startup when using Imdisk with the image backup/restore feature ? (image saved on shutdown, then restored on boot)

 

My system booting quite fast, it allows me to log into a windows session faster than the time it needs to load the RAMdrive's image.. this cause

Dropbox to crash on every boot, poping that error:

tLcETbc.png

The times for my system to automatically rebuild the RAMDrive and remount the image, forces me to to wait ~30-45sec on the windows session logon screen before actually logging-in wihtout causing a crash.



#12 v77

v77

    Silver Member

  • Team Reboot
  • 570 posts
  •  
    France

Posted 24 January 2016 - 11:46 AM

Any one here has Dropbox issue on windows startup when using Imdisk with the image backup/restore feature ? (image saved on shutdown, then restored on boot)
 
My system booting quite fast, it allows me to log into a windows session faster than the time it needs to load the RAMdrive's image.. this cause
Dropbox to crash on every boot, poping that error:
tLcETbc.png
The times for my system to automatically rebuild the RAMDrive and remount the image, forces me to to wait ~30-45sec on the windows session logon screen before actually logging-in wihtout causing a crash.

Did you try to put your data into a simple folder, instead of using a whole image file? For instance, if your image file is half empty, half of the data are read for nothing...
Moreover, with an image file, the ramdisk is ready only after the image file is fully loaded. But with a folder, the file system and the TEMP folder are ready almost immediately.

By the way, if you are using Windows 8 or later, and the fast startup feature of Windows is enabled, you should not use the data synchronization feature of ImDisk Toolkit, because it simply does not work at system shutdown (nothing is saved nor removed). I am currently adding a warning message about this because this cannot be fixed.

#13 xyBogli

xyBogli

    Newbie

  • Members
  • 29 posts

Posted 24 January 2016 - 11:58 AM

Did you try to put your data into a simple folder, instead of using a whole image file? For instance, if your image file is half empty, half of the data are read for nothing... You mean through the "Use Mount point" option within ImDisk Toolkit ? I will make the change, because yea, my image is almost 90% unused (~1Gb out of 22)

 

Edit: When I use the "Mount Point" instead of the "Load content from image", the syncronization feature within toolkit seems to get grayed out.. will it syncronize or not ?

 

What are the Pro/Con of those three Backup&Restore methods ?

- Load content from Folder

- Load content from Image

- Use Mount Point

 

 

Moreover, with an image file, the ramdisk is ready only after the image file is fully loaded. But with a folder, the file system and the TEMP folder are ready almost immediately. This should be indicated somewhere somewhat .. Thanks

By the way, if you are using Windows 8 or later, and the fast startup feature of Windows is enabled, you should not use the data synchronization feature of ImDisk Toolkit, because it simply does not work at system shutdown (nothing is saved nor removed). I am currently adding a warning message about this because this cannot be fixed. Using 7, but plan to move on to 8 soon (maybe 10, i'll see) .. anyway, the warning will be greatly welcomed !

 

Thanks


Edited by Boogyxy, 24 January 2016 - 12:06 PM.


#14 v77

v77

    Silver Member

  • Team Reboot
  • 570 posts
  •  
    France

Posted 24 January 2016 - 12:29 PM

You mean through the "Use Mount point" option within ImDisk Toolkit ? I will make the change, because yea, my image is almost 90% unused (~1Gb out of 22)

No. A mount point is meant to replace a drive letter. This is where you see the ramdisk content.
In fact, a drive letter is just a special mount point...

I was speaking to replace your image by a folder, with the same content than your image file, and to select it in the same field than the one where you select the image file (Data tab).
Of course, the synchronization option is grayed if nothing (neither image file nor folder) in this field is selected.

#15 xyBogli

xyBogli

    Newbie

  • Members
  • 29 posts

Posted 24 January 2016 - 01:44 PM

No. A mount point is meant to replace a drive letter. This is where you see the ramdisk content.
In fact, a drive letter is just a special mount point...

I still don't see the difference between using the "Use Mount Point" and a "load content from Folder"

... can you please clarify ? From what you say, it means the sames.. there might be some concept you take for granted, that I don't know of..

I was speaking to replace your image by a folder, with the same content than your image file, and to select it in the same field than the one where you select the image file (Data tab). Of course, the synchronization option is grayed if nothing (neither image file nor folder) in this field is selected.

Because of my misunderstanding of the Mount Point thing, I can't understand either how a Mounting point could not get syncronized just as well as an image or a folder..

 

:dubbio:



#16 v77

v77

    Silver Member

  • Team Reboot
  • 570 posts
  •  
    France

Posted 24 January 2016 - 02:10 PM

I still don't see the difference between using the "Use Mount Point" and a "load content from Folder"
... can you please clarify ? From what you say, it means the sames.. there might be some concept you take for granted, that I don't know of..

The mount point shows your ramdisk, like a drive letter. So, it cannot be the data stored on your hard drive...
A "mount point" is a directory that does not point to your hard drive but to the ramdisk (when the ramdisk is mounted, this directory becomes a "junction" that points to an object handled by the imdisk driver).

The data of your hard drive, that are located in an image file or a folder, are identified with the first field of the Data tab.

#17 xyBogli

xyBogli

    Newbie

  • Members
  • 29 posts

Posted 24 January 2016 - 03:02 PM

The mount point shows your ramdisk, like a drive letter. So, it cannot be the data stored on your hard drive...
A "mount point" is a directory that does not point to your hard drive but to the ramdisk (when the ramdisk is mounted, this directory becomes a "junction" that points to an object handled by the imdisk driver).

The data of your hard drive, that are located in an image file or a folder, are identified with the first field of the Data tab.

Well if the mount point shows my ramdisk, what is the purpose of that option considering that Imdisk already knows my RAM Drive's volume letter and that it already uses it as the default Mounting Point... not sure to understand what is this additional "Mount Point" field for....

 

Could you give a concrete use-case exemple sot that I can figure it out ?

(why one would use that Mount Point, instead of leaving it empty and let ImDisk uses the RAM Drive's volume letter as the default Mounting Point ?)



#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15104 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 January 2016 - 03:35 PM

You mean format /x (or similar options to for instance chkdsk) to force dismount? That works - but has occasionally about the same trouble with some filesystem drivers logging errors for non-pnp disks if there were references open to a few specific directories on the volume.
 

No, I actually meant format /q (but I could well be wrong :dubbio:)

I mean you are in that stage in which you want to "delete"  the Ramdisk (which is "volatile" by definition), so you don't have anymore any interest in its contents, so you can well format it (the /q option should make the operation a little quicker),

I was wondering if that action (which is performed by the Windows built-in tool) may "release" the *whatever*  that causes the issue. :unsure:

 

:duff:

Wonko







Also tagged with one or more of these keywords: debug

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users