What would I eye need to look up to determine how to determine the number of disk clusters that are marked bad.
I got a new win32.hlp file, it has a lot more functions than my older one had.(Like NT specific stuff)
Thanks.
Just had a quick search of my MSDN and found nothing. I'd suggest Google. It'll be a tough search though, good luck :U
Cheers,
Zooba
You'll probably have to count them from the cluster table.
For FAT volumes, this isn't so hard as you can get the details of the format quite easily (www.wotsit.org (http://www.wotsit.org)) and you then just load the table into memory and count the clusters labelled as bad.
For NTFS volumes, you're in for a struggle as microsoft like to keep it a secret. However, you might be able to find some info from the linux implementation (searchy!)
Generally, specific ones are no concern to you, the OS manages the space as a resource. More specific, the modern hard drives do substitutions/replacements on bad sectors, so where physically ( after LBA translation ) is encoded in the tracks. Which the hardware on the drive only knows, not the OS. The OS looks it up by logical addressing. There were utilities that could change the sector interleave, for speed reasons. But not necessary on the modern drives.
So I'm curious to know, what are you doing, where this information would become useful to you ???
Regards, P1 :8)
Quote from: P1 on January 03, 2006, 05:57:05 PM
Generally, specific ones are no concern to you, the OS manages the space as a resource. More specific, the modern hard drives do substitutions/replacements on bad sectors, so where physically ( after LBA translation ) is encoded in the tracks. Which the hardware on the drive only knows, not the OS. The OS looks it up by logical addressing. There were utilities that could change the sector interleave, for speed reasons. But not necessary on the modern drives.
So I'm curious to know, what are you doing, where this information would become useful to you ???
Regards, P1 :8)
That's top secret, I could tell you, but then I would have to snuff you out. :-) Just kidding.
No, my hard drive is getting more and more bad clusters. I am backing up frequently, so when it does finally go, no problemo.
Looking for a quick way to show the no. of bad clusters. I could learn some new win32 stuff as well.
I was supposed to already have my NEWER system, but the person forget
to get it from their MIL who is out of town. I may drive down to get it. It's a P-3, with Win 2K and I forgot what else it has.
Outta her,
Andy
Andy,
If you are running Windows 98 (IIRC) you can monitor the number of bad sectors with Scandisk. And although it is slow, the thorough option can do a surface scan of the disk for new bad sectors. But I think you could get a better idea of the drive's condition by obtaining the proper test program from the drive manufacturer and using it to perform a test of the drive interface, controller, etc, and a non-destructive scan of the disk surface. Assuming an IDE drive, if the manufacturer's test shows bad sectors, the drive is in trouble, and it probably needs to be replaced. The test program may have an option that will allow it to 'recover" the bad sectors, probably by re-mapping them to spare sectors, but the required low-level format will destroy all data on the drive. Within my experience, even if the low-level format succeeds in eliminating the (apparent) bad sectors, the drive is likely to fail completely in the near future. With the price of IDE drives now so low, if I suspect a drive is failing, I replace it.
Also, if your system BIOS supports S.M.A.R.T. you could enable it, and this might allow the drive itself to alert you to an impending failure.
Quote from: MichaelW on January 05, 2006, 03:39:45 AM
Andy,
If you are running Windows 98 (IIRC) you can monitor the number of bad sectors with Scandisk. And although it is slow, the thorough option can do a surface scan of the disk for new bad sectors. But I think you could get a better idea of the drive's condition by obtaining the proper test program from the drive manufacturer and using it to perform a test of the drive interface, controller, etc, and a non-destructive scan of the disk surface. Assuming an IDE drive, if the manufacturer's test shows bad sectors, the drive is in trouble, and it probably needs to be replaced. The test program may have an option that will allow it to 'recover" the bad sectors, probably by re-mapping them to spare sectors, but the required low-level format will destroy all data on the drive. Within my experience, even if the low-level format succeeds in eliminating the (apparent) bad sectors, the drive is likely to fail completely in the near future. With the price of IDE drives now so low, if I suspect a drive is failing, I replace it.
Also, if your system BIOS supports S.M.A.R.T. you could enable it, and this might allow the drive itself to alert you to an impending failure.
Thanks for the info.
I have the S.M.A.R.T enabled. I checked into 6 GB hard drives and I could only find a used one.
I won't have this computer too much longer. (hopefully)
I would sure like to know how big a drive my BIOS supports even if I couldn't get a new one.
If the current drive is 6GB then the next likely limit would be the 8.4GB CHS addressing limit. In general, if the BIOS supports the Interrupt 13h Extensions then it can use the full capacity of drives > 8.4GB. This DOS program reads and displays the contents of the MBR if the Interrupt 13h Extensions are installed, or displays an error message if they are not. Although it will run under Windows 98, it would probably be better to run it from a boot diskette.
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
.model small,c
.386
.stack
.data
DiskAddressPacket STRUCT
packetSize db SIZEOF DiskAddressPacket
reserved db 0
blocksToTransfer dw 0
bufferOffset dw 0
bufferSegment dw 0
startBlockLow dd 0
startBlockHigh dd 0
DiskAddressPacket ENDS
dap DiskAddressPacket <>
buffer db 512 dup(?)
msgNoSupport db 13,10,"No support",13,10,"$"
msgFuncError db 13,10,"Function error",13,10,"$"
msgExit db 13,10,"Press any key to exit$"
.code
.startup
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
; Make sure the Interrupt 13h Extensions are installed,
; and that the major version is at least 1.0, and that
; bit 0 of the API subset support bitmap is set,
; indicating that the fixed disk access subset (func
; 42h-44h, 47h, and 48h) is supported.
mov ax,4100h
mov bx,55aah
mov dx,80h ; First fixed disk.
int 13h
; Carry set = function not supported.
; Note that under Windows XP and probably 2000 the
; function will always return with carry set.
jc noSupport
; If the value returned in BX is not AA55h (note
; reversal), then the extensions are not installed.
cmp bx,0aa55h
jne noSupport
; The major version is returned in AH.
cmp ah,1
jb noSupport
; The API subset support bitmap is returned in CX.
test cl,1
jz noSupport
; Set up to read the master boot record (the first
; sector) for the first fixed disk. For the Interrupt
; 13h Extensions, blocks = sectors, but unlike
; sectors, logical blocks are numbered from zero.
mov dap.blocksToTransfer,1
mov dap.bufferOffset,OFFSET buffer
mov dap.bufferSegment,ds
mov dap.startBlockLow,0
mov ah,42h
mov dx,80h
mov si,OFFSET dap
int 13h
jnc @F
mov ah,9
mov dx,OFFSET msgFuncError
int 21h
jmp fini
; Display the contents of the buffer.
@@:
mov cx,512
mov si,OFFSET buffer
cld
printLoop:
; Filter out control characters because the Write
; Teletype function responds to some of them.
lodsb
cmp al,' '
jb @F
; Filter out the extended characters to avoid
; having too much garbage on the screen.
cmp al,'z'
ja @F
mov ah,0eh
int 10h
dec cx
jnz printLoop
jmp fini
@@:
mov ah,0eh
mov al,'.'
int 10h
dec cx
jnz printLoop
jmp fini
noSupport:
mov ah,9
mov dx,OFFSET msgNoSupport
int 21h
fini:
mov ah,9
mov dx,OFFSET msgExit
int 21h
mov ah,0
int 16h
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
.exit
end
There are other BIOS-dependent limits beyond 8.4GB, most commonly starting in the vicinity of 30GB. Ultimately, the only way you can be sure that a particular drive size is supported is to try it. The drives are intended to be backward compatible, so you can generally use a drive that is larger than what the system BIOS can support, just not the full capacity of the drive.
Skywalker,
Sounds like you would be a perfect customer for SpinRite, the great-great-great-great grandson of the amazing speed-reinterleaving tool mentioned earlier in this thread! It's a remarkable program that now manages low-level disk problems by reporting accurately the failure rate of the disk surface in particular sectors by testing writes and reads to the area rigorously, where other programs like Scandisk just skimp on the test. It can predict failures long before your data actually disappears because it finds how reliable writing/rewriting actually is across the whole disk surface. It also has considerable data recovery potential if the worst happens...
SpinRite has been around for years and years, and is widely recognised as a must-have utility. The author, Steve Gibson, proudly writes only in Assembler, so you'd be supporting one of our own... :U A good browse around his great website will throw up many other useful free gizmos and is worth it for the ShieldsUp port-probe test (which tests how vulnerable your computer is to external port attacks) alone. Everyone should visit.
http://www.grc.com/sr/spinrite.htm
IanB
Quote from: MichaelW on January 05, 2006, 03:46:28 PM
If the current drive is 6GB then the next likely limit would be the 8.4GB CHS addressing limit. In general, if the BIOS supports the Interrupt 13h Extensions then it can use the full capacity of drives > 8.4GB. This DOS program reads and displays the contents of the MBR if the Interrupt 13h Extensions are installed, or displays an error message if they are not. Although it will run under Windows 98, it would probably be better to run it from a boot diskette.
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
.model small,c
.386
.stack
.data
DiskAddressPacket STRUCT
packetSize db SIZEOF DiskAddressPacket
reserved db 0
blocksToTransfer dw 0
bufferOffset dw 0
Thanks. I need to know where to get the 16 bit MASM assembler and linker.
[/quote]
The ChkDSK output will tell him the number bad sectors without to much hassel. That way he can keep track if the count changes.
Regards, P1 :8)
QuoteI need to know where to get the 16 bit MASM assembler and linker.
The version of MASM included in the MASM32 package can assemble 16-bit programs, and you can get the 16-bit linker here.
http://spiff.tripnet.se/~iczelion/download.html
The download is a self-extracting archive that contains the linker and several other files. The 32-bit linker and the 16-bit linker are both named LINK.EXE, so take care not to overwrite the 32-bit linker. I normally rename the 16-bit linker to LINK16.EXE. As a minimum, you can assemble and link with these command lines:
ML /c filename.asm
LINK16 filename.obj;
Quote from: MichaelW on January 05, 2006, 03:46:28 PM
If the current drive is 6GB then the next likely limit would be the 8.4GB CHS addressing limit. In general, if the BIOS supports the Interrupt 13h Extensions then it can use the full capacity of drives > 8.4GB. This DOS program reads and displays the contents of the MBR if the Interrupt 13h Extensions are installed, or displays an error message if they are not. Although it will run under Windows 98, it would probably be better to run it from a boot diskette.
There are other BIOS-dependent limits beyond 8.4GB, most commonly starting in the vicinity of 30GB. Ultimately, the only way you can be sure that a particular drive size is supported is to try it. The drives are intended to be backward compatible, so you can generally use a drive that is larger than what the system BIOS can support, just not the full capacity of the drive.
[/quote]
Your program worked fine, my HD it supports the Int 13 extensions.
I tried a 120 GB a while back I got new for $20 and it didn't work.
I'll see if I can find a new 8 GB, though I am not hopeful. I found a used 6 GB for $15.00, but I'd be afraid
it wouldn't last long.