I have used InitDisk successfully on USB flash drives of 1GB, 2GB, 8GB, 16GB, 32GB and 64GB, as well as a 128GB microSD using a USB Type A adapter, on a notebook PC running Windows 10, version 22H2. All the hardware is from the mid 2010's (except the microSD).
However, InitDisk does not terminate "gracefully" when it encounters a USB drive that is Read-only/ Write-protected.
Some of the USB drives listed above were write protected at either the software (Windows) and hardware (drive controller) levels.
When you run InitDisk and enter "NUKE", the "====================[ PROBABLE WRITE PROTECTION ]======================" message is displayed, and you must terminate the program by pressing "ESC" so that you can disable the write protection as a separate action before running InitDisk a second time to complete the format process.
When InitDisk is terminated after it detects the drive as being Write-protected during the "NUKE" process, the USB drive loses its drive letter assignment. So, the drive is no longer detectable by Windows File Explorer (including the "Safely Remove Hardware...." popup in the Taskbar).
Since File Explorer can no longer detect the drive, you cannot re-assign a drive letter through the "Properties" menu for the drive. Unfortunately, you cannot re-assign a drive letter using "Disk Management" either, as that option is greyed out when you right-click on the drive within the Disk Management Utility.
CORRECTION OPTION 1: If you execute InitDisk a second time after terminating the first run, a drive-letter becomes re-assigned during the second InitDisk detection process. When you terminate the program normally by pressing "ESC" (do NOT enter "NUKE" a second time), everything returns to normal except the drive is still Write-protected.
HICCUP #1: I experienced the scenario where InitDisk did NOT detect the USB drive when executed a second time. So, neither Windows nor InitDisk was able to get a drive letter re-assigned to the USB Drive. Since "Disk Management" is not able to re-assign a drive letter either (discussed above), the only recourse when this happens is to use Diskpart (described below as CORRECTION OPTION 2).
HICCUP #2: I also occasionally experienced times where InitDisk detected the USB drive when executed for the second time, but a drive letter was not re-assigned during the discovery process. I was able to work around this by executing InitDisk a third time and, after the discovery process, terminate the program (without entering "NUKE", of course) by X-ing out of the program (upper right corner) instead of by pressing "ESC" - Windows re-assigns a drive letter at that time. This situation seemed to be a random occurrence. So, I'm not sure if it would happen to everyone, or if it is just an anomaly tied to my PC system.
CORRECTION OPTION 2: Use Diskpart to re-assign the drive letter. I found that regardless of how Windows or InitDisk works with a USB drive when the drive loses its drive letter assignment, Diskpart appears to be the "universal fix". A drive letter can be assigned to either the disk or its volume(s). Since drive letters are actually assigned to a volume(s) on the drive (not the drive itself), it is best to use Diskpart at the volume level. However, assigning a drive letter at the disk level could be appropriate if the drive has only a single volume, or if you wanted all of the volumes on the drive to be Read-only,
Once the drive letter assignment issue is fixed, the problem of removing the write protection still has to resolved.
1. If write protection is at the software level, then it can be disabled using Diskpart or by using a third-party software utility. NOTE: With third-party software, it is not uncommon that the third-party utility has to be used for BOTH setting and clearing the Read-only attribute. I found that I could not clear a Read-only configuration using Diskpart when the attribute was set by using third-party software (happened with two of the three utilities that I tried).
2. If write protection is at the hardware level, then the USB drive controller has to be re-configured to disable it. To do that, you need a utility provided by either the manufacturer of the USB drive for the particular model of drive being used (not that common); or by the controller chip OEM (which is a different "fun experience" in itself) that can re-program the Write-protect bit specifically or re-flash the controller configuration in its entirety (where the Write-protect parameter is one of numerous parameters that are configured for the re-programming process).
3. The easiest way that I found for determining if a Read-only (Write-protected) drive is at the software or hardware level is by using Diskpart. In Diskpart work at the disk (not volume) level - by default, Windows does not allow setting/ clearing the Read-only attribute at the volume level).
a. List the available disks: DISKPART > list disk
b. Select appropriate disk: DISKPART > select disk xx
c. View disk attributes: DISKPART > attributes disk
d. Clear Read-only: DISKPART > attributes disk clear readonly
NOTE 1: The attributes listing at the disk level shows two Read-only settings: "Current Read-only State" and "Read-only". When a USB drive is Write-protected (at either the software or hardware levels), the "Current Read-only State" will always say "Yes". The "Read-only" setting may or may not have teh same status, depending on the configuration source (most likely at the software level if it says "Yes").
NOTE 2: If both the "Current Read-only State" and "Read-only" parameters say "Yes", and the drive was actually set to Read-only at the software level, then both parameters should be cleared after entering the "clear readonly" command.
4. After clearing the Read-only attribute, check the attributes listing again: DISKPART > attributes disk - If both "Current Read-only State" and "Read-only" say "No", then the Read-only attribute was set at the software level and the drive is no longer Write-protected. If the Read-only attribute was set at the hardware level, then "Current Read-only State" will continue say "Yes"; the drive is still Write-protected, and you now have a whole new problem to deal with.
5. If you use a third-party program to remove the Read-only setting, then afterwards try to write to the drive, delete something on the drive, or format the drive. If you still receive the "write-protected" message, the Read-only attribute was set at the hardware level and you have more work to do. For some reaon software utilities (including Diskpart) always report success when removing the Read-only setting, even if it doesn't work (because the attribute was set at the hardware level). This is a false positive report and so it is best to test the drive to insure that the operation was successful.
After the write protection issue is rectified, InitDisk should work as advertised. To date, I have not experienced any other issues with InitDisk. But there are a lot of different makes of USB drives out there of varying quality, so you never know....
However, InitDisk does not terminate "gracefully" when it encounters a USB drive that is Read-only/ Write-protected.
Some of the USB drives listed above were write protected at either the software (Windows) and hardware (drive controller) levels.
When you run InitDisk and enter "NUKE", the "====================[ PROBABLE WRITE PROTECTION ]======================" message is displayed, and you must terminate the program by pressing "ESC" so that you can disable the write protection as a separate action before running InitDisk a second time to complete the format process.
When InitDisk is terminated after it detects the drive as being Write-protected during the "NUKE" process, the USB drive loses its drive letter assignment. So, the drive is no longer detectable by Windows File Explorer (including the "Safely Remove Hardware...." popup in the Taskbar).
Since File Explorer can no longer detect the drive, you cannot re-assign a drive letter through the "Properties" menu for the drive. Unfortunately, you cannot re-assign a drive letter using "Disk Management" either, as that option is greyed out when you right-click on the drive within the Disk Management Utility.
CORRECTION OPTION 1: If you execute InitDisk a second time after terminating the first run, a drive-letter becomes re-assigned during the second InitDisk detection process. When you terminate the program normally by pressing "ESC" (do NOT enter "NUKE" a second time), everything returns to normal except the drive is still Write-protected.
HICCUP #1: I experienced the scenario where InitDisk did NOT detect the USB drive when executed a second time. So, neither Windows nor InitDisk was able to get a drive letter re-assigned to the USB Drive. Since "Disk Management" is not able to re-assign a drive letter either (discussed above), the only recourse when this happens is to use Diskpart (described below as CORRECTION OPTION 2).
HICCUP #2: I also occasionally experienced times where InitDisk detected the USB drive when executed for the second time, but a drive letter was not re-assigned during the discovery process. I was able to work around this by executing InitDisk a third time and, after the discovery process, terminate the program (without entering "NUKE", of course) by X-ing out of the program (upper right corner) instead of by pressing "ESC" - Windows re-assigns a drive letter at that time. This situation seemed to be a random occurrence. So, I'm not sure if it would happen to everyone, or if it is just an anomaly tied to my PC system.
CORRECTION OPTION 2: Use Diskpart to re-assign the drive letter. I found that regardless of how Windows or InitDisk works with a USB drive when the drive loses its drive letter assignment, Diskpart appears to be the "universal fix". A drive letter can be assigned to either the disk or its volume(s). Since drive letters are actually assigned to a volume(s) on the drive (not the drive itself), it is best to use Diskpart at the volume level. However, assigning a drive letter at the disk level could be appropriate if the drive has only a single volume, or if you wanted all of the volumes on the drive to be Read-only,
Once the drive letter assignment issue is fixed, the problem of removing the write protection still has to resolved.
1. If write protection is at the software level, then it can be disabled using Diskpart or by using a third-party software utility. NOTE: With third-party software, it is not uncommon that the third-party utility has to be used for BOTH setting and clearing the Read-only attribute. I found that I could not clear a Read-only configuration using Diskpart when the attribute was set by using third-party software (happened with two of the three utilities that I tried).
2. If write protection is at the hardware level, then the USB drive controller has to be re-configured to disable it. To do that, you need a utility provided by either the manufacturer of the USB drive for the particular model of drive being used (not that common); or by the controller chip OEM (which is a different "fun experience" in itself) that can re-program the Write-protect bit specifically or re-flash the controller configuration in its entirety (where the Write-protect parameter is one of numerous parameters that are configured for the re-programming process).
3. The easiest way that I found for determining if a Read-only (Write-protected) drive is at the software or hardware level is by using Diskpart. In Diskpart work at the disk (not volume) level - by default, Windows does not allow setting/ clearing the Read-only attribute at the volume level).
a. List the available disks: DISKPART > list disk
b. Select appropriate disk: DISKPART > select disk xx
c. View disk attributes: DISKPART > attributes disk
d. Clear Read-only: DISKPART > attributes disk clear readonly
NOTE 1: The attributes listing at the disk level shows two Read-only settings: "Current Read-only State" and "Read-only". When a USB drive is Write-protected (at either the software or hardware levels), the "Current Read-only State" will always say "Yes". The "Read-only" setting may or may not have teh same status, depending on the configuration source (most likely at the software level if it says "Yes").
NOTE 2: If both the "Current Read-only State" and "Read-only" parameters say "Yes", and the drive was actually set to Read-only at the software level, then both parameters should be cleared after entering the "clear readonly" command.
4. After clearing the Read-only attribute, check the attributes listing again: DISKPART > attributes disk - If both "Current Read-only State" and "Read-only" say "No", then the Read-only attribute was set at the software level and the drive is no longer Write-protected. If the Read-only attribute was set at the hardware level, then "Current Read-only State" will continue say "Yes"; the drive is still Write-protected, and you now have a whole new problem to deal with.
5. If you use a third-party program to remove the Read-only setting, then afterwards try to write to the drive, delete something on the drive, or format the drive. If you still receive the "write-protected" message, the Read-only attribute was set at the hardware level and you have more work to do. For some reaon software utilities (including Diskpart) always report success when removing the Read-only setting, even if it doesn't work (because the attribute was set at the hardware level). This is a false positive report and so it is best to test the drive to insure that the operation was successful.
After the write protection issue is rectified, InitDisk should work as advertised. To date, I have not experienced any other issues with InitDisk. But there are a lot of different makes of USB drives out there of varying quality, so you never know....
