Brad Banko writes: >While running the MS Quick C compiler in a DOS window under Windows 3.1  >this evening, I got a "program has violated system integrity... close all  >applications, exit windows and restart your computer" error.  Gawd, I love Windows :-)  >1)  Is there an easy way to restore everything to working order? >What might be some better approaches?  You'll probably want to delete any damaged executables and reload them fresh.  Data files should be examined and repaired.  >2)  What might have caused this?  Does the SMARTDRV cache make me more >vulnerable?  (I'm suspicious of hard drive caches especially when they >cache data writing.)  You're not stupid.  Smartdrive caches things, and Windows also runs a swap file which may contain data also.  All of this is pretty risky stuff in a PC environment.  >The straightforward approach would be to run chkdsk with the /f option to  >fix the disk and then it looks like I would probably have to reinstall Windows >and a few other things.  A reasonably accurate prediction...   Here's a brief description of how DOS stores files:  There are three pieces to a file.  The directory entry, the FAT chain, and the data area.  You can think of these as a sheet of lined notebook paper, a sheet of graph paper, and a stack of 3X5 cards.  The directory entry (notebook paper) holds the file name, actual size, and first cluster number.  It also holds some other information that's not important right now.  The File Allocation Table (FAT) chain (graph paper) tells where to find the actual data.  Each square of graph paper holds a number.  If the number is zero, the cluster associated with this box is available.  If it holds a "magic" number, it is either the last piece of a file or a bad (unuseable) spot on the disk.  Any other number tells which cluster contains the next section of the file.  The data area (3X5 cards) is where the actual information is stored. The data area is organized as clusters of a fixed size; storage is doled out in "chunks" of one cluster each.  (In your case, one cluster is 2048 bytes.)  As a cluster is filled, another is allocated.  To read a file, you first look at the directory entry to get the starting cluster number.  Now you read the data from that cluster. Next, look at the FAT entry for the cluster you just read.  This will tell you the cluster number for the next chunk of the file. Naturally, these numbers are usually sequential, but they can jump around and even go backwards.  Continue reading, one cluster at a time, as you walk this chain through the FAT, until you hit the marker which says it's the last cluster in the file.  CHKDSK is the DOS utility that checks the sanity and coherence of the directories and the FAT and can bludgeon most flaws into submission.  It doesn't have any intelligence, so you have to double-check anything it "fixes".  Now let's do a bit of a post-mortem:  >C:\GFX\VPIC46\CVPIC.EXE >C:\GFX\VPIC46\VPIC.TXT >C:\GFX\VPIC46\VIDEO7.CFG >C:\GFX\VPIC46\ORCPRO2.CFG >C:\GFX\VPIC46\VGA.CFG >C:\GAME\GOOSE\BIRD2.X >C:\WINMISC\ADV21\WINADV.EXE >   Allocation error, size adjusted  All of these files have sizes (according to the FAT) which don't match the size reported in their directory entries.  CHKDSK /F will alter the directory entries to match the FAT size.  (In other words,   the directory entry for CVPIC.EXE may say the file is 64,877 bytes long. But CHKDSK found a FAT chain of 43 clusters attached to it.  (My numbers, obviously, are made up.))  >   316 lost allocation units found in 224 chains. >    647168 bytes disk space would be freed  Disk space was found which is allocated in the FAT, but is not attached to any directory entry.  CHKDSK /F gives you the option of converting these "lost chains" to files.  You can then examine the files (FILE0000.CHK through FILE0223.CHK) and rename or discard them.  Or, if you tell CHKDSK _not_ to convert them to files, then those clusters will simply be marked "available" in the FAT.   >C:\GFX\VPIC46\CVPIC.EXE >   Is cross linked on allocation unit 16133  ...  >C:\386SPART.PAR >   Is cross linked on allocation unit 16133  These files are both referencing the _same_ data cluster.  Obviously, one of them (at least) must be wrong.  It's interesting to note that C:\386SPART.PAR is your Windows swap file...  To fix this, you should copy each cross-linked file to a new name. This will "fix" the cross-link by giving the files unique data spaces. Now delete the cross-linked files.  Examine the copies and try to assemble them properly.  Good luck.  (Hint:  "Missing pieces" are likely to be found in those "lost chains" at the top...)  >  42366976 bytes total disk space >   3958784 bytes in 4 hidden files >    153600 bytes in 67 directories >  36042752 bytes in 1496 user files >   1564672 bytes available on disk  Your disk is pretty close to full.  This may be the actual cause of the problem; perhaps Windows needed to expand its swapfile by an amount which exceeded available disk space...  In any case, the short summary is that something trashed your FAT. There are utilities that can mirror your FAT and help repair damage after something like this, but you have to run them _before_ the problem occurs.  Sorry.   --  ---------------------------------------------------- Gordon S. Hlavenka           cgordon@vpnet.chi.il.us Vote straight ticket Procrastination party Dec. 3rd! --