Hi,
I am doing some testing with mounting of VHDs. DiskPart is used, a new VHD is created and assigned either a letter or a mount point (not both).
It seems random, but when the letter/mount point is removed, I get an instance teardown event, even though the volume is still there, we should not be getting an instance teardown right?
Regards, Dejan.
Correct…If all that’s happening is the deleting of the mount point then you shouldn’t see an instance teardown. However, I don’t know what else that code does. Maybe it tries to dismount the file system before removing the mount point?
That would be random DiskPart behaviour then.
All I do is call “REMOVE” on the assigned letter, and sometimes it calls
teardown, sometimes not.
I’m thinking that it might always try but it might not always work (e.g. a HANDLE open somewhere). Do you have a ProcMon trace?
Peculiar,
I get instance teardown, instance context Cleanup, but create file I/O
keeps coming for the volume far after instance teardown, even though no new
InstanceSetup is there…
Some of these started aftet teardown.
And yep, I have ProcMon log.
Do you see an FSCTL_DISMOUNT_VOLUME?
No, the only i/o of interest is a LOCK volume.
I debugged more and a new instance mount happens before the old instance
teardown. That is why it looked like we get only a teardown, log did not
imclude instance data on IRP MJ CREATE to be sure which instance is used.
Now, IIRC, lock volume does this 
So the question remains why a new mount
is always called before old teardown (though I can see this can happen…),
and why it does not happen on most OSes
Dejan.
There’s no guarantee that you’ll see a new instance only after an old teardown (e.g. the old instance can still be in use in the case of forced dismount or surprise removal).
Is this behavior causing issues or just a curiosity?
I think I identified a bug in my code, the assumption which occurs first.
So, I think this is totally OK, just took time to figure.
Thanks!