Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu!mjf From: mjf@cunixb.cc.columbia.edu (Michael J Flory) Newsgroups: comp.windows.ms Subject: Re: Strange memory errors in Windows? Summary: Correcting my explanatory vagaries... Message-ID: <1991May29.063900.22751@cunixf.cc.columbia.edu> Date: 29 May 91 06:39:00 GMT Article-I.D.: cunixf.1991May29.063900.22751 References: <1991May29.005554.10290@cunixf.cc.columbia.edu> Sender: usenet@cunixf.cc.columbia.edu (The Network News) Reply-To: mjf@cunixb.cc.columbia.edu (Michael J Flory) Organization: Columbia University Lines: 51 Nntp-Posting-Host: cunixb.cc.columbia.edu Andrew Colfelt kindly replied to my query about errors copying disks in Win3: >mjf@cunixb.cc.columbia.edu (Michael J Flory) writes: >>Some time ago I posted with a strange and dangerous error I got running >>DISKCOPY in a DOS window with a .pif asking for all 640 K if it could get >>it. In short, the diskcopy operation miscopied a couple of sectors every >>dozen-and-a-half or so (the number varied). But although VERIFY was on, >>I got no error message -- I discovered it through DISKCOMP. >The best way to avoid this would be to run the DOS window full-screen. It >sounds a little like the floppy errors could be caused by the switching of >CPU attention. When you're 'multitasking' in Windows and performing a >sensitive operation like copying sector-for-sector, the time-lag, skip, >stutter, whatever, the window is causing a lack of proper 'attention' to the >process and thus bytes are getting dropped. >Try DISKCOPY in DOS, full-screen, and see if the problem goes away. Better >yet, try the window again, with the BackGround Box checked. If the disks >still lose bytes, try full-screen, BackGround. One of these setups should >allow the CPU to devote sufficient attention to the copying process to >maintain good housekeeping on all bytes in all sectors. Thanks very much for the advice. When I read it I realized, though, that I hadn't explained myself too clearly. I carelessly interchange "in a window" and "in a windows session" and I did it here -- I *think* I ran things in full-screen when I got the errors. I usually do just 'cause it's faster. But I am going to experiment a little and see if I can duplicate the error in a window and out. Also, I always check the "background" box when I run things in the background -- as I usually run them full-screen. The thing that struck me about the errors was their regularity. In the DISKCOPY problem, I got messed-up cylinders at regular intervals: for example, cylinders 4, 5, 28, 29, 52, 53, ... might be bad (I'm making the numbers up, and the intervals and exact values varied, but the patterning was of that sort consistently). In the (related?) problem copying files under XTREE GOLD 2.0, the *beginnings* of the files were bad (it never started in the middle of a file) and every other byte was wiped out, ending on a nice even offset (e.g. 10000 hex). That's why I started by looking for a bad RAM chip. I'll experiment a little more and follow up. If Windows is allowing an application to access more memory than it is really protecting, this could be something nasty. Oh -- yes, I am running a '386DX in Enhanced Mode. I use Fastopen, Smartdrive, Himem, and Ramdrive in 4 megs of RAM, and aside from too many device drivers I don't think there's anything exceptional about my setup. Again, thanks very much for the help! Michael Flory (mjf@cunixb.cc.columbia.edu)