Archived from groups: alt.comp.periphs.videocards.nvidia,alt.games.wolfenstein,microsoft.public.windowsxp.general (More info?)

Today when I booted my computer checkdisk ran automatically, "fixed" some
errors, and simply rebooted leaving me in a state of cluelessness.

Fortunately I could retrieve the information via:

Event Viewer->Application Source:WinLogon:

Here is the chkdisk report:

"
Checking file system on C:
The type of the file system is NTFS.


One of your disks needs to be checked for consistency. You
may cancel the disk check, but it is strongly recommended
that you continue.
Windows will now check the disk.
Index entry nvoglnt.dll of index $I30 in file 0x1d points to unused file
0xc958.
Deleting index entry nvoglnt.dll in index $I30 of file 29.
Index entry resume.el of index $I30 in file 0xc76b points to unused file
0xc959.
Deleting index entry resume.el in index $I30 of file 51051.
Index entry Unit1.dfm of index $I30 in file 0xc90d points to unused file
0xc95a.
Deleting index entry Unit1.dfm in index $I30 of file 51469.
Index entry Unit1.pas of index $I30 in file 0xc90d points to unused file
0xc95b.
Deleting index entry Unit1.pas in index $I30 of file 51469.
Cleaning up minor inconsistencies on the drive.
Cleaning up 48 unused index entries from index $SII of file 0x9.
Cleaning up 48 unused index entries from index $SDH of file 0x9.
Cleaning up 48 unused security descriptors.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.

11550703 KB total disk space.
10344776 KB in 215692 files.
91180 KB in 22706 indexes.
0 KB in bad sectors.
321155 KB in use by the system.
65536 KB occupied by the log file.
793592 KB available on disk.

4096 bytes in each allocation unit.
2887675 total allocation units on disk.
198398 allocation units available on disk.

Internal Info:
54 e1 03 00 49 a3 03 00 62 8c 05 00 00 00 00 00 T...I...b.......
60 27 00 00 00 00 00 00 f0 01 00 00 00 00 00 00 `'..............
20 85 2e 12 00 00 00 00 20 08 2c db 01 00 00 00 ....... .,.....
f0 05 5b 0e 00 00 00 00 00 00 00 00 00 00 00 00 ..[.............
00 00 00 00 00 00 00 00 40 0b c2 06 02 00 00 00 ........@.......
99 9e 36 00 00 00 00 00 8c 4a 03 00 00 00 00 00 ..6......J......
00 20 65 77 02 00 00 00 b2 58 00 00 00 00 00 00 . ew.....X......

Windows has finished checking your disk.
Please wait while your computer restarts.


For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
"

Then later when I tried to start "Return to Castle Wolfenstein Multiplayer
Demo":

"
Wolf 1.1 win-x86 Dec 17 2001
----- FS_Startup -----
Current search path:
F:\GAMES\Return to Castle Wolfenstein Multiplayer DEMO/main

----------------------
0 files in pk3 files

Running in restricted demo mode.

----- FS_Startup -----
Current search path:
F:\GAMES\Return to Castle Wolfenstein Multiplayer DEMO\demomain\pak0.pk3
(1846 files)
F:\GAMES\Return to Castle Wolfenstein Multiplayer DEMO/demomain

----------------------
1846 files in pk3 files
execing default.cfg
couldn't exec language.cfg
execing wolfconfig_mp.cfg
usage: seta <variable> <value>
execing autoexec.cfg
Hunk_Clear: reset the hunk ok
....detecting CPU, found Intel Pentium III
Bypassing CD checks
----- Client Initialization -----
----- Initializing Renderer ----
-------------------------------
Loaded 714 translation strings from scripts/translation.cfg
----- Client Initialization Complete -----
----- R_Init -----
Initializing OpenGL subsystem
....initializing QGL
....calling LoadLibrary( 'C:\WINDOWS\System32\opengl32.dll' ): succeeded
....setting mode 3: 640 480 FS
....using colorsbits of 32
....calling CDS: ok
....registered window class
....created window@0,0 (640x480)
Initializing OpenGL driver
....getting DC: succeeded
....GLW_ChoosePFD( 32, 24, 0 )
....35 PFDs found
....GLW_ChoosePFD failed
....failed to find an appropriate PIXELFORMAT
....restoring display settings
....WARNING: could not set the given mode (3)
....setting mode 3: 640 480 FS
....using colorsbits of 16
....calling CDS: ok
....created window@0,0 (640x480)
Initializing OpenGL driver
....getting DC: succeeded
....GLW_ChoosePFD( 16, 24, 0 )
....35 PFDs found
....GLW_ChoosePFD failed
....failed to find an appropriate PIXELFORMAT
....restoring display settings
....WARNING: could not set the given mode (3)
....shutting down QGL
....unloading OpenGL DLL
....assuming '3dfxvgl' is a standalone driver
....initializing QGL
....WARNING: missing Glide installation, assuming no 3Dfx available
....shutting down QGL
----- CL_Shutdown -----
RE_Shutdown( 1 )
-----------------------
GLW_StartOpenGL() - could not load OpenGL subsystem
"

Apperently checkdisk was bold enough to simply delete these four files:

Index entry nvoglnt.dll of index $I30 in file 0x1d points to unused file
0xc958.
Deleting index entry nvoglnt.dll in index $I30 of file 29.

Index entry resume.el of index $I30 in file 0xc76b points to unused file
0xc959.
Deleting index entry resume.el in index $I30 of file 51051.

Index entry Unit1.dfm of index $I30 in file 0xc90d points to unused file
0xc95a.
Deleting index entry Unit1.dfm in index $I30 of file 51469.

Index entry Unit1.pas of index $I30 in file 0xc90d points to unused file
0xc95b.
Deleting index entry Unit1.pas in index $I30 of file 51469.

This is not enough information for me, I want to know in what folder these
files were so I can asses the damage better.

Apperently nvoglnt.dll is related to opengl which is now damaged.

resume.el ? I have no idea what this is. Maybe a harmless file of
somebodie's resume which I got via spam/e-mail... maybe a virus... maybe
just a continue file for some program.

Unit1.dfm and Unit1.pas is some delphi source code.... I would like to know
which one has been deleted since I have many of these files on my PC....
it's probably not an important one... but stilll I would like to make sure.

How do I restore my system ? Do I simply install the latest nvidia driver
and hope for the best ?

How did this happen in the first place ? (I have been playing around with
RTCW and a debugger which I shutdown multiple times but I dont think that
was dangerous ? )

Some scenerio's

1. Some kind of crash corrupted it

2. Windows xp pro contains a bug somewhere which corrupted it

3. RTCW has a bug somewhere overwriting this file and corrupting it.

4. Somebody broke into the pc and corrupted it on purpose.

5. A virus/worm corrupted it.

Is there anything that can be done to make chkdsk give more information and
maybe ask me what I want it to do before it does it ?

Well so much for that

Bye,
Skybuck.

Archived from groups: alt.comp.periphs.videocards.nvidia,alt.games.wolfenstein,microsoft.public.windowsxp.general (More info?)

"DaveL" <dave1027@comcast.net> wrote in message
newsvKdnZ7B7PmMAEzcRVn-qA@comcast.com...
> He'll screw around with a debugger but won't trust disk utilities?

Nope these utitilities are complex and hard to understand and before you
know... you're doing a low level format heheheheh.

Archived from groups: alt.comp.periphs.videocards.nvidia,alt.games.wolfenstein,microsoft.public.windowsxp.general (More info?)

"DaveL" <dave1027@comcast.net> wrote in message
newsvKdnZ7B7PmMAEzcRVn-qA@comcast.com...
> He'll screw around with a debugger but won't trust disk utilities?

Yeah.... I'll pass on disk utilities that do a low level format to "test"
the drive LOL.

Bye.
Skybuck

Archived from groups: alt.comp.periphs.videocards.nvidia,alt.games.wolfenstein,microsoft.public.windowsxp.general (More info?)

Besides....

I checked this site:

http://www.hitachigst.com/hdd/support/download.htm

It does mention possibility of losing data... scary.

But even if I wanted to give it a go...

I dont have a diskdrive anymore hehehehehehe removed yessss to make room for
the king the new drive... so it s cooool.

I could make a bootable cd... but spending on 1 euro on it is LOL to much
what a waste

Archived from groups: alt.comp.periphs.videocards.nvidia,alt.games.wolfenstein,microsoft.public.windowsxp.general (More info?)

On Tue, 28 Dec 2004 12:22:34 +0100, "Skybuck Flying"
>"Spack" <news@worldofspack.co.uk> wrote in message
>> "Skybuck Flying" <nospam@hotmail.com> wrote in message

>> > Today when I booted my computer checkdisk ran automatically, "fixed"
>> > some errors, and simply rebooted leaving me in a state of cluelessness.

Two bad OS design "features" at work here:

1) Auto-fixing ChkDsk (or really in this case, AutoChk)
2) Automatically reboot on system errors

Even if you say "well, unattended servers would want reboot on errors
to maintain downtime", what's the point of rebooting on errors that
arise before the OS boot process is complete?

Fortunately, you can (and IMO should) kill (2) via System, Properties,
Advanced etc. Unfortunately, the UI design of ChkDsk and AutoChk date
from before MS-DOS 6 brought Scandisk to the world, so they simply
don't offer any interactive (user-controlled) mode of operation at all

>> > Apperently nvoglnt.dll is related to opengl which is now damaged.
>> Sounds like it - nvoglnt sounds like nVidia OpenGL NT driver - and XP is
>> NT5.1.

>> No idea about the other files.

Not only do AutoChk and ChkDsk /F automatically "fix" without
prompting you, but they bury their results deep in the bowels of Event
Viewer. Not somewhere obvious like "ChkDsk", but "Winlogin" or
something. It's hard to read that material if XP can't boot.

>Well since only the opengl dll was damaged I was lucky and simply installed
>the latest nvidia drivers and voila it s working again

>> Either turning the power off before cached updates have been
>> written back to the hard drive, or hard disk could be on the way out.
>> Get the disk utilities for the drive you have from the manufacturers
>> web site and run a few tests.

>why would anything write to the dll ? Except maybe defrag or repairing the
>dll or something wacky.

Yes, code files would normally be written to only when:
- installed
- updated
- infected
- disinfected
- moved by defrag
- "fixed" by ChkDsk or AutoChk
- splatted by wild writes

HD file system (structure, i.e. that ChkDsk can detect) can be
corrupted in various ways:

1) Interruption of sane writes

This is what ChkDsk and AutoChk ASSume is going on, when they "fix"
things, and what NTFS's vaunted "transaction rollback" is designed to
mitigate (though the small print says only metadata is protected).

2) Wild writes

If the file system's layer of abstraction is undermined by bad RAM or
other flaky hardware, or deranged/malicious software, then the file
system's "rules" may be broken too. For example, a data cluster
destined for volume cluster address 63412 may be bit-punned (by a
reset address bit) to 30644, and thus overwrite data from some
completely unrelated file. At the lower level of raw sector
addresses, this can corrupt the raw bones of the file system itself.

3) Bad HD

Just about everything conspires to hide HD failure from you. First,
the HD's own firmware "fixes" rotting sectors on the fly; then NTFS's
code does the same thing, and finally ChkDsk /R paints over bad
clusters and ignores existing ones. And by default, CMOS setup
disables SMART reporting on POST. So it's up to you to suspect this
possibility whenever the mouse pointer sticks with the HD LED on (bad
sector retries) and chase it up before your data's hosed.


On HD diagnostics: Yes, take care to avoid destructive tests, and
abort testing as soon as physical errors show up and proceed directly
to evacuating your data, from outside "I can't run without writing to
C:, too bad if that kills the data" Windows.

SMART reporters from HD vendors will look at the SMART history and
typically go "hmmm, only a few thousand wobbly sectors that so far
we've auto-'fixed'... OK, call it a 'good' HD, no need to issue an
RMA". Don't accept a glib one-line "everything's fine" report; use
something like AIDA32 to show you all the detail that SMART can cough
up. SMART's potentially good in that it's the only window into bad
sectors that are already hidden by the firmware's "fixing".

In addition, use something that can non-destructively check the HD
surface. Watch for slowdowns in the progress - if outside of
Windows's constant background tasks, they can be taken to mean retries
of sick sectors - even if the utility says everything is "OK".



>---------- ----- ---- --- -- - - - -
"He's such a character!"
' Yeah - CHAR(0) '
>---------- ----- ---- --- -- - - - -

Archived from groups: alt.comp.periphs.videocards.nvidia,alt.games.wolfenstein,microsoft.public.windowsxp.general (More info?)

cquirke (MVP Win9x) wrote:
> Well, VFAT is the code that manages FATxx, and FATxx doesn't have an
> MFT. The most crucial file system structure in FATxx is the FAT
> themselves, and because these are so crucial, FATxx maintains two
> copies and updates them both within such a small critical period that
> "mismatched FAT" from interruption of sane file ops is very rare.
>
> What does "better" file system NTFS do about hedging against
> interrupted MFT updates? AFAIK, nothing beyond keeping duplicates of
> a handful of crucial system entries. It's a case of the OS saying
> "I'm alright Jack; too bad about your data".

NTFS is journalled, so if any sequence of file system operations was
interrupted there should be a record of what was being done in the
journal so that the missing operations can be reconstructed. Therefore
there should be no way for the file system structure to become corrupted
due to an unclean shutdown. Normally a full chkdsk is not necessary in
this situation since the journal can be quickly replayed. I suspect in
this case something else happened to cause some on-disk corruption of
the file system data structures..

--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Archived from groups: alt.comp.periphs.videocards.nvidia,alt.games.wolfenstein,microsoft.public.windowsxp.general (More info?)

On Wed, 29 Dec 2004 17:54:09 GMT, Robert Hancock
>cquirke (MVP Win9x) wrote:

>> What does "better" file system NTFS do about hedging against
>> interrupted MFT updates? AFAIK, nothing beyond keeping duplicates of
>> a handful of crucial system entries. It's a case of the OS saying
>> "I'm alright Jack; too bad about your data".

>NTFS is journalled, so if any sequence of file system operations was
>interrupted there should be a record of what was being done in the
>journal so that the missing operations can be reconstructed.

What specifically does journalling keep a backup of, that it can undo?

I ask, for two reasons:

1) MS's documentation suggests only metadata is preserved

2) Performance impact implies data cluster chains aren't duplicated

For example; I add two bytes at offset 37600 in a 125000567-byte file.
If journalling was to *totally* preserve the state of the original
file, it would have to retain all clusters from the original file from
that containing the offset, onwards, plus the original dir entry, plus
the old chaining info (which as I understand it, is not a "FAT" but a
set of start addresses for the cluster runs that make up the file).

Is this what journalling does? Or something rather less than this?

>Therefore there should be no way for the file system structure to
>become corrupted due to an unclean shutdown.

I suspect the devil may be in the details on this one ;-)

>Normally a full chkdsk is not necessary in this situation since
>the journal can be quickly replayed.

Sometimes, you may *want* the broken remains of the file that was
being created or updated, which journalling is likely to throw away.

If you disable AutoChk, does that also disable the journalling
"automatic fixing" feature as well?

>I suspect in this case something else happened to cause some
>on-disk corruption of the file system data structures.

That's my suspicion, too. These things happen, and when they do, NTFS
is far less fixable (in the sense of "preserve or recover my files"
rather than "do whatever it takes to sanify the file system" )


>--------------- ----- ---- --- -- - - -
Never turn your back on an installer program
>--------------- ----- ---- --- -- - - -

Archived from groups: alt.comp.periphs.videocards.nvidia,alt.games.wolfenstein,microsoft.public.windowsxp.general (More info?)

cquirke (MVP Win9x) wrote:
> On Wed, 29 Dec 2004 17:54:09 GMT, Robert Hancock
>
>>cquirke (MVP Win9x) wrote:
>
>
>>>What does "better" file system NTFS do about hedging against
>>>interrupted MFT updates? AFAIK, nothing beyond keeping duplicates of
>>>a handful of crucial system entries. It's a case of the OS saying
>>>"I'm alright Jack; too bad about your data".
>
>
>>NTFS is journalled, so if any sequence of file system operations was
>>interrupted there should be a record of what was being done in the
>>journal so that the missing operations can be reconstructed.
>
>
> What specifically does journalling keep a backup of, that it can undo?
>
> I ask, for two reasons:
>
> 1) MS's documentation suggests only metadata is preserved
>
> 2) Performance impact implies data cluster chains aren't duplicated
>
> For example; I add two bytes at offset 37600 in a 125000567-byte file.
> If journalling was to *totally* preserve the state of the original
> file, it would have to retain all clusters from the original file from
> that containing the offset, onwards, plus the original dir entry, plus
> the old chaining info (which as I understand it, is not a "FAT" but a
> set of start addresses for the cluster runs that make up the file).
>
> Is this what journalling does? Or something rather less than this?

In the case of NTFS I believe that only file system metadata is
preserved, i.e. the file system is guaranteed to be consistent, however
files that were being written at the time of the crash could contain old
data, new data, or a mixture of the two. There are some other file
systems that have stronger guarantees (Reiser4 on Linux is claiming to
have all file system operations fully atomic with no performance hit,
and I believe even ext3 has better guarantees than this by default).

Even in those cases though, the operation you describe wouldn't be
atomic, since that can't be done through a single file system operation
(you can't just tell the OS to insert data in the middle of a file, you
have to write the new data and then move the rest of the contents down
yourself).

--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Archived from groups: alt.comp.periphs.videocards.nvidia,alt.games.wolfenstein,microsoft.public.windowsxp.general (More info?)

On Sat, 01 Jan 2005 07:58:43 GMT, Robert Hancock
>cquirke (MVP Win9x) wrote:
>> On Wed, 29 Dec 2004 17:54:09 GMT, Robert Hancock

>>>NTFS is journalled, so if any sequence of file system operations was
>>>interrupted there should be a record of what was being done in the
>>>journal so that the missing operations can be reconstructed.

>> What specifically does journalling keep a backup of, that it can undo?

>> 1) MS's documentation suggests only metadata is preserved
>> 2) Performance impact implies data cluster chains aren't duplicated

>In the case of NTFS I believe that only file system metadata is
>preserved, i.e. the file system is guaranteed to be consistent, however
>files that were being written at the time of the crash could contain old
>data, new data, or a mixture of the two.

Well, that's the point. What you are saying is that the NTFS
journalling feature does absolutely nothing to preserve your data.

>Even in those cases though, the operation you describe wouldn't be
>atomic, since that can't be done through a single file system operation
>(you can't just tell the OS to insert data in the middle of a file, you
>have to write the new data and then move the rest of the contents down
>yourself).

Quite. What you'd have to do, if you wanted to claim perfect
preservation of the previous state, is to write the new material to
unused clusters, then chain these into place, and finally update the
dir entry to point to the new form of the file as an atomic operation.

I'd do that by first adding the chain as am ADS, and then switching
pointers so that it becomes the main data stream, then I'd drop and
unlink the old version of the file.

But the performance impact could be really ugly, and one of the
drawbacks being you'd need space for both new and old file chains.


In practice, MS is not concerned with your data at all; only the
sanity of the file system. After all, the only impact these matters
have on MS is in terms of support calls. No vendor assumes any
responsibility for your data, so from their perspective, it's
irrelevant. From your perspective, it's the only unique part of the
system that cannot be restored by throwing money at new parts.

The trouble is, these matters will only come to a head when things go
wrong. Even then, the user has to believe what the tech says, and
many techs are insufficiently skilled or concerned about data
recovery. So bogus claims like "NTFS saves you from data loss because
of journalling and transaction rollback" are rarely challenged.



>--------------- ----- ---- --- -- - - -
Tech Support: The guys who follow the
'Parade of New Products' with a shovel.
>--------------- ----- ---- --- -- - - -

Archived from groups: alt.comp.periphs.videocards.nvidia,alt.games.wolfenstein,microsoft.public.windowsxp.general (More info?)

cquirke (MVP Win9x) wrote:
>
> In practice, MS is not concerned with your data at all; only the
> sanity of the file system. After all, the only impact these matters
> have on MS is in terms of support calls. No vendor assumes any
> responsibility for your data, so from their perspective, it's
> irrelevant. From your perspective, it's the only unique part of the
> system that cannot be restored by throwing money at new parts.
>
> The trouble is, these matters will only come to a head when things go
> wrong. Even then, the user has to believe what the tech says, and
> many techs are insufficiently skilled or concerned about data
> recovery. So bogus claims like "NTFS saves you from data loss because
> of journalling and transaction rollback" are rarely challenged.
>

I think that the main claimed advantage of NTFS journaling is that it
avoids the need for a full chkdsk after an unclean shutdown. This is not
such a big deal for a home system, but if you have a server containing
hundreds of user profiles and many thousands of files, the time it takes
to run a full file system check is very significant (many hours in
some cases, apparently), during which time the server is not available.

There are some advantages as far as data integrity however - in FAT32,
etc. there are probably some cases where the file system state after a
crash can't be reconciled properly and some files end up orphaned or
lost, NTFS would prevent this from happening.

--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/