EWF with Hibernation, second unprotected volume with file coruptio

[Guest]

Hi all,

my problem is this Microsoft description:

see
http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.windowsxp.embedded

Design Considerations for Using EWF with Hibernation

For example, your system has two volumes, one protected and one unprotected.
If you create a file on the unprotected volume and restart the system, that
file will not be known to the operating system on the next reboot because the
cached information about the volume was not copied to the hibernation file.
Although when you create the hibernation file on the disk, the system is
unaware of the file. This can create an inconsistency between what data is
actually on disk and what data the system is aware of.

Problem!
My systems has two volumes, one protected and one unprotected.
I want disable the cached information of the unprotected volume
or disable the control of unprotected volume?
The system believes the files are corruption after boot, that is not so.
The volumes has NTFS.

What can I do?

 

[Slobodan Brcin \(eMVP\)]

Frank,

What link?
Try:
http://msdn.microsoft.com/library/d...mesInHibernateOnceResumeManyConfiguration.asp

Regards,
Slobodan

 

[Guest]

Hi Slobodan,

thank you, gives another or faster solutions?

Can I manually operate dismount the volume for check?

Have a good weekend.

 

[Slobodan Brcin \(eMVP\)]

Hi Frank,

You must do dismount and hibernate from within your application. This is the
only way to 100% guarantie that FS will stay closed.

Regards,
Slobodan

 

[KM]

Frank,

If by manually operate you mean dismounting the volume from, say, Explorer (although, there is no such functionality available) -
then no, you have to Lock the volume and dismount it. Then you hibernate your image.
When the image resumes you will have to Unlock it and close the handle.

As Slobodan pointed out, this is all easy achievable within your own application code.

 

[Slobodan Brcin \(eMVP\)]

Frank,

When the image resumes you will have to Unlock it and close the handle.

Actualy it is simpler that this. You can just exit your application and
windows will do this for you automaticaly.

Regards,
Slobodan

 

[KM]

Yup. Agree.

I just prefer a clean/clear code, not leaving to Windows to do the defaults for my apps/drivers. Otherwise it may sometimes be hard
to find roots of possible issues with the code

 

[Slobodan Brcin \(eMVP\)]

I must say that I have never seen any problems on XP with abnormal
termination of processes. XP close all handles and dealocate all memory
alocated to process that is terminated.

Also I agree that closing handles and doing reverse operations is a good
thing for debugging purposes and good programming practice.

Regards,
Slobodan

 

[KM]

Slobodan,

Well... I can't say I have seen much problems from non-closed handles under XP (or even NT/2K).
However, I have spent some good time debugging similar problems under Windows 95/98 (sounds like the same Win32 world but we all
know it is not!) where non-closed GDI handles were leading to hard-to-find memory leaks. That time I got a good habit to control all
the handles within my code.

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

Yup problems were there on non NT versions, but on NT there are not because
HANDLE management is not done in Win32 subsustem but much lover in kernel
mode.

Regards,
Slobodan

 

[KM]

Slobodan,

Yup. That is one of the big advantadges of NT.
However, I still think it is necessary to close properly all handles since an applicaiton (user mode) can depend on some
comunication with a buggy driver (kernel mode).

Just a hypotetical scenerio (I never tried that) that potentially can lead to a leak in system resources.
Application has two threads. First thread uses a shared object (named mutex, for instance) that is also used by a driver. Second
thread makes a call to DeviceIoControl on the same driver. Within the Ioctl processing code the driver waits for the mutex to be
released.
Now if you terminate the application (no call to CloseHandle), or application code exits without the explicit call to CloseHandle,
the driver never returns from the Ioctl code since the mutex was not released. So the application's second thread will never be
terminated and the aplication itself either. You will end up with the dead process that does not go away until a major system clean
up (logoff or shutdown on XP).

Regards,
Konstantin

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

Driver waiting for user mode create mutex sound like an awfull idea in the
first place. Second idea about driver waiting in Ioctl handler sound even
worse (but someone might do it).
I do not know what will happen in this case but I thing that handle will be
signaled and closed by TerminateProcess function.

Look at SDK doc about TerminateProcess:

Remarks
The TerminateProcess function is used to unconditionally cause a process to
exit. Use it only in extreme circumstances. The state of global data
maintained by dynamic-link libraries (DLLs) may be compromised if
TerminateProcess is used rather than ExitProcess.

TerminateProcess initiates termination and returns immediately. This stops
execution of all threads within the process and requests cancellation of all
pending I/O. The terminated process cannot exit until all pending I/O has
been completed or canceled.

Terminating a process causes the following:


1.. All object handles opened by the process are closed.
2.. All threads in the process terminate their execution. Each thread
exits when all its pending I/O has been completed or canceled. The process
exits after all its threads exit.
3.. The state of the process object becomes signaled, satisfying any
threads that had been waiting for the process to terminate. The process
object is deleted when the last handle to the process is closed.
4.. The states of all threads of the process become signaled, satisfying
any threads that had been waiting for the threads to terminate.
5.. The termination status of the process changes from STILL_ACTIVE to the
exit value of the process.

Terminating a process does not cause child processes to be terminated.

Neither the process nor any DLLs attached to the process are notified that
the process is terminating. A process cannot prevent itself from being
terminated.

Terminating a process does not generate notifications for WH_CBT hook
procedures.



Regards,
Slobodan

 

[KM]

Slobodan,

I didn't say that was a good example. I even said that was a buggy driver.
But I saw implementations of some drivers that were far behind production quality and the example I described earlier was not the
worse case.

Also, I didn't say the mutex was created in user mode. It could be first created by the driver (it is shared object after all). It
is used in embedded world to implement communications between applications and driver that way.

I don't think OS will signal the mutex when terminating the process. (that mutex as well as any process internal objects are not
signaled, except the process handle and all thread signals).

The baseline - closing handles is more than just a good habbit

Konstantin

 

[Guest]

Hi,

thank you.
I'm looking for the current version of xpepm.dll,.h and .lib.
My version is 2.0.807.0.
I write an application now.

 

[KM]

Frank,

Interesting.. the version of the "xpepm.dll" I've got here is just 2.00.0620.0. There seemed to be no updates for XPePM App since
XPe RTM.
Where did you get the updated version?

 

[KM]

Oh, nevermind.
I remembered the newer version of the xpepm is under VALUEADD. I worder why the xpepm.dll are not synced between VALUEADD and
Repository.

 

[Guest]

Hi Slobodan,
hi KM,

gives problems with mapped network drives and hibernation & ewf?
Is this the same problem as a second unprotection volume or not?

 

[Slobodan Brcin \(eMVP\)]

Frank,

It could be a problem, although I thing that caching is done differently
sine network is not a stable resource.

From you application that does hibernation I would automaticaly disconect
all network volumes. And after resume I would try to mount them again.

Regards,
Slobodan

Hi Slobodan,
hi KM,

gives problems with mapped network drives and hibernation & ewf?
Is this the same problem as a second unprotection volume or not?