jaclaz

Well, if it works directly inside an elevated command prompt then it should work exactly the same when run through elevate.exe. Maybe it is the "mixed mode" that is the issue? dsfi is 32 bit. Try using the 32 bit elevate.exe, and try also from a non-elevated command prompt to run (it is well possible that the modified batch code isn't doing what I expected it to do, I have no way to test it directly): elevate.exe -c -w dsfi \\.\I: 0 0 as512.bss And/or try running this as a batch: dsfi \\.\I: 0 0 as512.bssECHO Errolevel is %ERRORLEVEL%maybe the Errorlevel is not set/parsed correctly? jaclaz

Making a new post so that Dave-H has more chances to notice it (as opposed to editing previous one). Ok. Get this: http://code.kliu.org/misc/elevate/ extract the elevate.exe from \elevate-1.3.0-redist.7z\bin.x86-32\ and copy it to the "J:" drive (the very small FAT12 drive). Edit the Switcher.cmd as follows: Near the beginning change (add a line): Near the end, change this: to: jaclaz

Good . So it is just a matter of detecting if the OS needs Admin privileges to run the dsfi command, and if they are needed, *somehow* elevate the privileges. I am not at all familiar with that UAC nonsense, but I'll have a look around, surely a suitable solution exists . jaclaz

Doesn't Regshot run on Windows 8.x? http://sourceforge.net/projects/regshot/ jaclaz

Good. So the issue here seems to be that either Windows 8.x *somehow* locks the volume or that the dsfi.exe command does not work in Windows 8.x (and this could be due to other reasons), or maybe there is the need to run them as Administrator because the command is UAC (or *whatever*) protected? Can you try using another dd-like tool? The general idea behind the batch is to overwrite first 4096 bytes of the second volume, which is on \\PhysicalDriven at LBA 2048) when mounted on a 512 bytes/sector) or at LBA 256 (when mounted on a 4096 bytes/sector) and is in both cases sector 0 of the \\.\LogicalDrive or aboslute offset in bytes 1048576 with either of: as512.bss <- if the disk is seen as 512 bytes/sector as4kb.bss <- if the disk is seen as 4096 bytes sector So, for the tests, if you make a folder on your "main" drive, say C:\mytemptest and copy to it those two files, you can try the following commands: on eSATA (where the disk is seen as 512) dsfi \\.\<drive letter> 0 0 as512.bss on USB (where the disk is seen as 4096) dsfi \\.\<drive letter> 0 0 as4kb.bss The above are the actual commands that the batch attempts to execute and should give you the same "access denied" error, but try them from a command prompt in "elevated" mode, maybe that is the issue. Alternative commands are: on eSATA (where the disk is seen as 512) dsfi \\.\Physicaldriven 1048576 0 as512.bss on USB (where the disk is seen as 4096) dsfi \\.\Physicaldriven 0 1048576 as4kb.bss Or try with dd for windows: http://www.chrysocome.net/dd the syntax will be: on eSATA (where the disk is seen as 512) dd if=c:\temptest\as512.bss of=\\.\<drive letter> bs=512 dd if=c:\temptest\as512.bss of=\\.\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} bs=512 <- use dd --list or mountvol to get the Volume x's dd if=c:\temptest\as512.bss of=\\?\Device\Harddiskm\Partition1 bs=512 <- use dd --list or to get the m, n on USB (where the disk is seen as 4096) dd if=c:\temptest\as4kb.bss of=\\.\<drive letter> bs=4096 dd if=c:\temptest\as4kb.bss of=\\.\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} bs=4096 <- use dd --list or mountvol to get the Volume x's dd if=c:\temptest\as4kb.bss of=\\?\Device\Harddiskm\Partition1 bs=4096 <- use dd --list or to get the m, n jaclaz

Generally speaking, yes, as a matter of fact I said "to/from", though as said it is not most probably the issue at hand. Each and every OS executable file compiled for 64 bit will be a bit larger than the corresponding one for 32 bit, or, if you prefer, the typical 32 bit install requirement is within 16 Gb, whilst the 64 bit will be around 20 Gb. jaclaz

You are trying to do too many things at once, following not the given procedure. Run the batch. If you are asked to type YES, type YES. If you type "yes", the batch will do NOTHING. You were asked to type "YES" (not "yes"). Try running the batch again. Type YES if prompted Then try running it again (the idea is that the batch can be run as many times as you want and if the volume is already with the "right" geometry it will confirm it, while if it is not it will prompt you to switch to the "other" geometry. It is possible that Windows 8.x (for it's own reasons) would not automatically assign a drive letter to the first or the second partition (or both), at least the first time that the disk is connected hence: jaclaz

More probably 8 Gb are needed. The "switch" with 4Gb or 6Gb does not make much sense (as I see it) consider also how in any case a 64 bit OS needs to transfer more data from/to the hard disk, though with SATA speedish disk this should not affect noticeably performance. jaclaz

Try again on the XP. Re-deploy the image under XP. What happens when you run the switcher.cmd? Which output do you get? On windows 8.x: What happens when you run the mountvol command? The Switcher.cmd is made with the scope to be run exclusively from the smallish volume that should be *always* mounted and always have a drive letter assigned, if this is not the case, try assigning a drive letter manually with mountvol or in the disk manager. jaclaz

Yep, missing "l" is a typo corrected in the original post. I don't think that Windows 8/8.x manages PhysicalDrives in any way differently from previous OS versions, at least up to Windows 7 dsfo/dsfi has no issues that I know of. Unless there is some kind of issues with UAC, disk protection or *whatever*. Maybe you need to take the disk offline in order to be able to deploy the image to it? http://www.eightforums.com/tutorials/53106-disk-set-offline-online.html In any case, you can deploy the image under XP and then test the result in Windows 8/8.1, the dsfi commands in the Switcher.cmd do not access the \\.\PhysicalDrive, but the (mounted) volume through it's drive letter, and they should not suffer from the same issue. jaclaz

Why anyone would want to use anything but the latest version of 7-zip on a .7z file is a mistery to me, however, get it as .zip. jaclaz dualmode.zip

Ok. Please find attached a test image, it is to create a NTFS volume about 100 Mb in size. You need to extract the image from the archive and then dd it to the target disk. If you don't have already a suitable dd-like tool, get the DSFOK tools from here: http://members.ozemail.com.au/~nulifetv/freezip/freeware/ and run the command: dsfi \\.\Physicaldriven 0 0 dualmode.img where n is the number of the disk as seen in disk manager. (be careful to choose the right n) Disconnect and reconnect the disk. What should happen: opening explorer you should see two added drive letters one of the two will be relative to a (very small) volume 68 Kb in size open this drive and in it there will be (among other files) a Switcher.cmd run it, it will - if needed - switch between 512 bytes/sector and 4096 bytes/sector filesystem for the second volume copy to this second volume a few files disconnect/remove the disk and connect it again through the "other" interface repeat steps #1 to #4 check that the files you wrote in step #5 are still there, normally accessible, etc. use the second volume indifferently though the one or the other interface.Points of note: the disk will remain set to the bytes sector relative to the "last run" of Switcher.cmd, so, when you re-connect it through "the other" you NEED to run the Switcher.cmd again (while if you re-connect it through "the same" it is optional and only useful to verify that the volume was mounted correctly).if you double click on explorer on the second drive letter, if the bytes/sector are set "the other way" you will be prompted to format the drive, DO NOT do it, it simply means that you must run the switcher.cmd.the drive/volume should behave normally in everything, including CHKDSK, but DO NOT use Disk Manager or any other tool to modify the partitioning.Limitations: there can be only two volumes on the disk, one is the pre-made very small volume and one for "all the rest" this setup is intended for a NON-bootable disk, maybe it could be possible to make it bootable, but ONLY through the interface that exposes the device as 512 bytes/sector If the experiment succeeds, I will put together a set of instructions and a batch to the effect of the following: you connect the disk through the USB interface (i.e. the one that exposes the device as 4096 bytes/sector) you create normally from within the Windows a NTFS partition using all your disk space (starting by default from sector 256*4096 or 2048*512 or offset 1,048,576) and format it you run a few commands to "convert" the disk to the "dual mode" settings jaclaz dualmode.7z

Yes and no. The 2.2 Tb limit is in the 32 bit wide field in the MBR but it only applies to 512 bytes sectors. Once you get to 4096 bytes sectors there are no issues up to 8 times that size. NTFS as a filesystem is fully compliant with non-512 bytes sectors, and as as well CHKDSK and FORMAT seem like working fine. The Disk Manager (and possibly the diskpart) may on the other hand have some problems with them and the use of a third party tool (or of another later NT OS) may be needed. As well fsutil will not work fully. As hinted before the issue with BIOS is that most of them are simply badly coded and believe that a device MUST have 512 bytes sectors, once we have removed the BIOS from the equation (as all NT operating systems use a HAL or Hardware Abstraction Layer) the issue may lie in the drivers used by the OS to access the disk. There was a Windows 7 update (that essentially is made out of a bunch of updated disk/port drivers) http://support.microsoft.com/kb/2510009/en-us http://support.microsoft.com/kb/982018/en-us and one for Vista: http://support.microsoft.com/kb/2553708/en-us (but this one is less relevant, as it is mainly about specific ESENT compatibility and an updated fsutil) I guess that we will need to wait and see, right now I believe that some combo hardware+manufacturer drivers have no issues, while other ones may have them (and it is unlikely that the motherboard manufacturer will issue new drivers for XP). jaclaz

Dave-H, are you game to play "lab rat" ? I think I have a workaround for your situation, and even if it is not really *needed* anymore, if it works OK it could be of some use to someone in the same situation. If you are willing to test it, let me know and I will put together *something* that you will be able to test on your device (this will require of course a new partitioning/formatting of the disk). jaclaz

They are TWO separate issues (actually a single issue with two separate possible solutions, both not fully "sound"), let's not mix them together, please. The MBR partition scheme has LBA fields (let's set aside CHS ones that are not used by most modern OS anyway) that are 32bits. This makes any LBA address bigger than 2^32-1=4294967295 become "a suffusion of yellow". LBA address represent sectors or "blocks", on "normal" traditional media where sectors are 512 bytes each, this means that anything bigger than 4294967295*512=2,199,023,255,040 i.e. roughly 2.2 Tb cannot be represented. The "natural" solution to this would have been (and actually was and actually is) to make media with larger sectors, and the hard disk industry decided that the next bigger sector size that was more convenient (for a number of reasons) was 4096 bytes, and so-called AF or advanced Format disk drives were started being manufactured. With the MBR scheme the maximum addressable space becomes 4294967295*4096=17,592,186,040,320 i.e. roughly 17 Tb. The issue here is that a number of BIOSes (actually I believe almost all of them) were and are not compatible with a sector size different from 512 bytes (which rules out larger than 2.2 Tb disks from being a bootable device) and the good MS guys (that could have easily fixed OS support for 4 Kb sectored disk drives) for their own reasons decided to NOT fix the (BTW very little issues) on existing operating systems to have them operate with 4 Kb disks (which are only supported "fully" on 8.x and later). The good disk manufacturers then "invented" the so-called 512e drives, i.e. drives that are actually 4 Kb sectored but that expose themselves as being 512 bytes/sector as a "bridge" solution, and possibly for some "standardization" for mass production, they also started (senselessly) to make AF (i.e. 4 Kb sectored disks) with capacities well below the 2.2 Tb lmit. In the meantime the good MS guys got on the (largely senseless) UEFI/EFI/GPT bandwagon, and still in the meantime SSD's (that rarely exceed 512 Gb in size) became popular/available. Facts: a modern PC will likely use as boot device a SSD that will be smaller than 2.2 Tb, so the MBR and/or BIOS limits do not apply, or at least do not apply yet. any other disk device which is not a boot device can be MBR and as large as 17 Tb, as long as it is 4 Kb sectored. even XP (with some exceptions mainly related to Disk Manager) has no real issues with 4 Kb sectored devices, if they are not used to contain the boot or system partition (i.e. they are used as Data storage, which is what such large disk devices should be used for), the good guys that designed filesystems were smart enough :thumbsup to forecast the need - before or later - to change the size of the sector size.Lies or half-lies you have been told in the last few years: you need GPT (and not MBR) you need UEFI (and not BIOS) there is a limit of 2.2 TB with the MBR scheme, loop to #1 aboveThe reality is that the good MS guys intentionally (most probably to push the EFI/UEFI and consequently GPT, both specifications they however do not fully respect) avoided to provide proper support on the OS side to the initiative of the hard disk manufacturers (which could have been by itself a "good enough" solution to the 2.2 Tb limit) on the other hand the good guys that wrote the EFI/UEFI specifications did their best to prevent the use of GPT disks on BIOS (particularly to make them bootable on BIOS, which is actually perfectly possible, with a few little tricks), the net result being the current mess and misinformation. jaclaz

Be aware that the Vista structure uses hard links, so be very, very careful (this normally is not related to third party software, but if you are going to attempt moving parts of the OS, it may). jaclaz

Another thing to check (though it is more like shooting in the dark ) do they have the same current consumption? One of the "features" of USb devices is power consumption, maybe one has a lower value than the other? Like one beiing - say 100 mA and the ther being - still say - 300 mA? Try running this with both the 8 Gb and the 32 Gb connected and see if you can spot any difference (besides the obvious ones connected to size) : http://www.nirsoft.net/utils/usb_devices_view.html jaclaz

Strictly speaking COA2 needs not to be installed. The issue you are having is probably that it's installer is 16 bit. Can you "install" it to another PC running an earlier OS and then copy to the Vista machine just the coa2.exe and coa2.hlp? Or, alternatively try on the Vista machine to extract the files from the (Wise) installer, using an appropriate tool *like* WUN.EXE?: http://www.911cd.net/forums//index.php?showtopic=14906 https://web.archive.org/web/*/http://www.reatogo.de/sample/test-WUN.zip https://web.archive.org/web/20060915000000*/http://www.pediy.com/tools/unpack/Wise/WUN.rar jaclaz

Well, it's the first time I hear that a USB stick can be detected as CD/DVD (unless it is set to be one on one or both it's LUN's, or it is a stupid U3 stick) jaclaz

Interesting And scary/queer. Three questions: Are both the 32 Gb and the 8 Gb set as "Removable" (or as "Fixed")? (or are they differently set?) Are both the 32 Gb and the 8 Gb partitioned (or "superfloppy")? (or are they differently set?) Have you tried making a smaller than 8 Gb partition on the 32 Gb stick? (if it is partitioned)jaclaz

Good to have contributed to another happy bunny: http://www.msfn.org/board/topic/128727-cant-access-repair-my-pc-option-via-f8-startup/?p=828512 Well, with all due respect to your opinion, you have to understand how nlite is an "advanced" but "generic" tweaking/reducing/whatever tool, while people may have every kind of *needs* or *wishes* making them all happy through nlite would have further complicated the tool, the interface would have become more like a spreadsheet than anything else as you would have hundreds or thousands of possible chioices/settings. jaclaz

By any chance do you also find the ribbon interface of post 2003 MS Office to be "better" and more productive? jaclaz

I would still be curious to know how the disk is seen in Windows 8.x when directly connected to a SATA port. According to the mentioned resources: AF, 4K native -> 4096/4096 AF, 512e -> 512/4096 512n -> 512/512 The results of the previous tests seem to indicate that the adapter translates also the SATA channel so that what gets in is 512/4096 and what gets out is 512/512 on eSATA and 4096/4096 on USB. While Dencorso and NoelC were happily lingering in their consumerist laziness I did a few checks and, though I have not yet nothing of practical use, I can confirm that with a few byte patches it is possible to have the same NTFS filesystem mounted fine on either 512 or 4096 bytes sectored device, as a matter of fact I was surprised by the support (for access NOT booting) that good ol' Windows XP has for NTFS on 4kb sectored (virtual) devices, something that the good MS guys seemed to exclude a priori. jaclaz

Good mooorning , Mr. de La Palice: http://en.wikipedia.org/wiki/Jacques_de_La_Palice Sure , guess WHY newer version of Isobuster have this feature/WHO asked for it to its Author? http://www.msfn.org/board/topic/172655-strange-or-odd-multi-or-single-boot-cddvd-el-torito-images/ And - at least for these Acronis .iso's - the little batch here: http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/ http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/?p=189345 adds the possibility of using iso-hybrid booting with GRUB2. jaclaz

I would think that the initially given resource: http://www.msfn.org/board/topic/172917-integrating-patched-system-files-without-wfp-problems/ is simple enough, now that it also contains a practical example, detailed verbally AND in Hex / gsar syntax http://www.msfn.org/board/topic/172917-integrating-patched-system-files-without-wfp-problems/?p=1089478 What is the issue you are having with it? Your mission, should you accept it, is to change in those lines: %P to \(00) or, if you prefer (in a Hex editor): 25005000 to 5C000000 Then (this is what I am not too sure about ) you need to recreate the checksum of sfcfiles.dll, or at least this is what ElTorqiro suggested: http://www.msfn.org/board/topic/98306-wfp-app-for-removing-individual-files-from-monitoring/ ModifyPE: http://unattended.msfn.org/unattended.xp/view/web/16/#modpe though nowadays pechecksum is advised: http://www.msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/page-3#entry1078428 jaclaz