News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Determine number of bad clusters

Started by skywalker, January 01, 2006, 07:40:28 PM

Previous topic - Next topic

skywalker

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.

zooba

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

Tedd

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) 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!)
No snowflake in an avalanche feels responsible.

P1

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)


skywalker

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





MichaelW

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.

eschew obfuscation

skywalker

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.


MichaelW

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.

eschew obfuscation

Ian_B

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

skywalker

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]

P1

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)

MichaelW

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;
eschew obfuscation

skywalker

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.