Partitioning a 2tb hd for Windows 7 64 bit

  • Thread starter Thread starter Daniel Prince
  • Start date Start date
Alias <aka@maskedandano said:
I never back up the system, only data.

I'm not talking about backups. I'm talking about Windows loading system
files into memory - DLLs, the registry, etc. These can be corrupted by
faulty memory and then are written back to disk in a corrupt state.
 
GreyCloud said:
If he loves to troll, then he would feel at home in comp.os.linux.advocacy.

They're welcome to him. He's currently infesting uk.d-i-y where the
locals had him sussed straightaway.
 
They're welcome to him. He's currently infesting uk.d-i-y where the
locals had him sussed straightaway.

Another group that I have followed for years has had periodic
infestations. I see he has recently been posting there, too.

Sincerely,

Gene Wirchenko
 
I'm not talking about backups. I'm talking about Windows loading system
files into memory - DLLs, the registry, etc. These can be corrupted by
faulty memory and then are written back to disk in a corrupt state.

I don't think DLLs get written back to the disk.

They might be written to the swap file and read back, but they are not
written to the Windows directory tree.
 
I'm not talking about backups. I'm talking about Windows loading
system files into memory - DLLs, the registry, etc. These can be corrupted
by faulty memory and then are written back to disk in a corrupt state.

DLLs arent. And there are checks for corrupted registry too.
 
It is a complex situation.

Nope, very simple, actually.
If your program requires a function from a DLL file, it will load the dll
into ram. Then it depends on what the dll function will do... it could be
used to write data to a file, and if the ram that holds the dll got
corrupted for any reason (just one bit not set right) then the file may
not get written correctly,

And its completely trivial for code that needs to ensure that
cant happen to check that that hasn't happened to the code.

Even just a CRC on the code in ram before its executed will ensure that.
but most likely cause a crash. So it would be hard to say what the
outcome would e.

Not if you have enough of a clue to do a CRC
on the code before its executed in ram and
compare that with the CRC of the DLL etc.
Most of the time nothing is noticed tho. The average consumer will
usually not see anything, but one of the "once-in-a-blue-moon" crash or
freeze can happen.

And with code that needs to be complete robust, the
DLL will just be loaded again and when its CRC is correct
in ram, it will be executed and there wont be anything
more than an soft error logged.
In UNIX, when ram starts to get flakey, the kernel panic happens. That
means it is time to start replacing ram (95% of the time anyway).
The biggest problem will be backing up a file that is already corrupted.

Trivial to ensure that it cant ever be corrupted.
A checksum that is done on a corrupted file at that point won't do you
anygood.

But a CRC before its corrupted will.
Banking systems and critical data stores take the necessary steps to make
sure that the data is good.

And they arent actually stupid enough to spend anything
like $10K on the hardware when it can all be done in software.
 
Gene E. Bloch said:
I don't think DLLs get written back to the disk.

It was intended as an example. Any file that gets read into faulty
memory then written back out to disk is vulnerable.

Windows Update -> downloads an updated DLL info faulty memory -> gets
written to disk corrupted.

And what about %systemroot%\system32\dllcache ?
 
GreyCloud said:
It is a complex situation. If your program requires a function from a
DLL file, it will load the dll into ram. Then it depends on what the
dll function will do... it could be used to write data to a file, and if
the ram that holds the dll got corrupted for any reason (just one bit
not set right) then the file may not get written correctly, but most
likely cause a crash.

just as an aside (I'm probably teaching granny to suck eggs here)
Windows has "Windows File Protection" which can be invoked by 'sfc
/scannow'. This will check for corrupted system files.

But I agree that in mission critical applications, it's best to do
error-checking in hardware, identifying memory faults *before* they have
the opportunity to cause corruption.
 
Mike Tomlinson said:
It was intended as an example. Any file that gets read into faulty
memory then written back out to disk is vulnerable.

Windows Update -> downloads an updated DLL info faulty memory -> gets
written to disk corrupted.

And what about %systemroot%\system32\dllcache ?

If a dll is damaged by any mechanism, windows will see it as a corrupted dll
and will abort
when it is used.
 
Back
Top