jaclaz

You have a most queer idea of what "old" means. "My" old means: http://en.wikipedia.org/wiki/Vacuum_tube AL3, AL4, etc.: http://www.qsl.net/dl7avf/roehren/index.html and, at the most: http://en.wikipedia.org/wiki/Transistor BC107, BC108 2N3055..... jaclaz

Really? I didn't know that. I would have thought that asking an Electric Engineer would have been more appropriate. However you made a statement: Unless you have some superconducting material, since even a wire has a resistance, the "complete short" you were talking about is a logical impossibility. So, once we have ruled out the existance of a "complete short", there are two COMMON ways to do a "good enough short": using a short piece of wire or "jumper" using a 0 (zero) Ohm resistor Method #2 is COMMONLY used on modern PCB's, for the reasons explained in the given link: BTW - remember that the metrics you used in the past: http://www.msfn.org/board/index.php?showtopic=142620&st=38 may also apply here. jaclaz

Actually 0 (zero) Ohm resistors are quite common on modern PCB's : http://en.wikipedia.org/wiki/Zero-ohm_resistor jaclaz

Leave the program running, if the instructions for it say so. Generally speaking, Authors of recovery software don't get any advantage in making you scan a drive for a few hours unneededly, if their program wants to do the scanning, let it scan. jaclaz

Just to clear a bit the matter the converter is ALPHA-ALPHA , it may (or completely fail to) work. Namely, it won't - at the moment - convert "ALL" syntaxes, some need still to be added. There is now an online UPDATED version here: http://jaclaz.altervista.org/Projects/Convert_address.htm If anyone is a better javascript programmer then I am (very, very probable) and has any idea to better it, please PM me. jaclaz

Anyway, should it be of any use, attached is the small .htm Personally, I will use it to translate any link to it's "plain" syntax, to avoid this mess next time. jaclaz Edit: Attachment updated Convert_address.zip

For the record, this is Windows 7 "Batch language" or "Command interpreter" or "Command line" or "Command console", NOT DOS. jaclaz

Please describe "everything". Try clicking on gosh's signature (last post by gosh): http://www.msfn.org/board/apple-worth-more-than-walmart-t143010.html http://www.msfn.org/board/index.php?showtopic=143010 Gosh's XP Build Environment http://www.msfn.org/board/Gosh_s_XP_Build_Environment_t106064.html To recap: the board can ALWAYS use links using "index.php?showtopic=" syntax "previous" friendly names are NOT understood anymore "current" friendly names are exactly as "stoopid" as we don't have any way to know if in next board update the software will be changed yet another time. please, do also note that if you rename a topic, the friendly names goes "beserk" ANYWAY As an example, I renamed this topic: http://www.msfn.org/board/index.php?showtopic=141678 from "Installing Windows 2000" http://www.msfn.org/board/installing-windows-2000-t141678.html to "[sOLVED] Installing Windows 2000" http://www.msfn.org/board/solved-installing-windows-2000-t141678.html And obviously the friendly name changed and any link made to the topic will become invalid. I am writing a small javascript converter, hopefully capable to convert "friendly names" (either "old" or "new" syntax) to the "REAL" always good syntax, I'll post it as soon as I have time to finish it. jaclaz

Well, not really news, these drives have been around since a bit: http://www.infoworld.com/t/drives-and-arrays/transcend-antivirus-usb-flash-drive-trend-micro-032 http://www.transcendusa.com/Press/index.asp?LangNo=0&axn=Detail&PrsNo=1323 The model is the V15: http://www.transcendusa.com/products/ModDetail.asp?ModNo=245&LangNo=0&Func1No=&Func2No= http://www.transcendusa.com/Products/TrendMicro/TrendMicro.asp IMHO , since the vulnerability is due to the Autorun feature of some MS Operating Systems, it seems to me just crazy to use this to run the actual AntiVirus software. The antivirus is licensed for 90 days, then you have to pay for the updates. I find it more a Commercial/Advertisement intiative than a Technical idea. The approach of disabling the Autorun seems to me like a better approach: http://ninjapendisk.com/ http://www.boot-land.net/forums/index.php?showtopic=4350 then you let your "resident" antivirus take care of the non-USB Autorun related threats. jaclaz

Hey, mchldpy, remember not to go to computerguru's seminar next time! Heck, you asked it! BTW, in my experience, throwing up system volume info is quite unprobable, on the other hand throwing up any number of disk signatures happens quite often, it is said that it happens because of their often repetitive nature: http://thestarman.pcministry.com/asm/mbr/Win2kmbr.htm#DC but there is no definite evidence about this. jaclaz

I am not at all an expert in vbs, what I was suggesting, maybe improperly is that the drive letter is assigned anyway as long as a partition entry is created in the MBR (or in the EPBR), so all it is needed is to add a condition that triggers the format if DR.FileSystem equals whatever vbs returns for a drive not formatted, cannot say if "", 0, -255, "a suffusion of yellow", or anything else, something like *PSEUDO* CODE: If InStr(1,DR.FileSystem,"<whatever is returned on an unformatted volume>",1) Then jaclaz

I am an asterisk? You don't need to , just my small way to thank you for the great work you've done over the years with Qemu Manager. jaclaz

Yes, to re-iterate once again. Seagate has somehow admitted that a firmware bug (according to them affecting only a very limited number of drives made in a certain factory and in a given timeframe, and only some of them, coming from one or a few of the manufacturing lines) are affected by this "circular register" bug. Supposedly these few lines had incorrectly set in-factory testing procedure that left the drive in such a condition that when the drive LOG hit (320+n*256) with 0<=n<=255, the drive will lock. In English there is a term for the above, which I cannot write here, but is 8 letter long, starts with B, ends with T and has as middle letters LS, you get the idea. There are some posts dealing exactly with the issue and the reasons and the numbers possibly involved: From here: http://www.msfn.org/board/index.php?showtopic=128092&st=1007 for about 30 posts From here: http://www.msfn.org/board/index.php?showtopic=128092&st=1042 for about 50 posts What is not (as I see it ) properly perceived is that the log getting at 320 is just one of the possible causes for a bricking. Logically this should lead to EITHER a LBA0 OR a BSY problem, but since anything about the matter is actually hushed up by Seagate, and none has a way to investigate the matter properly, let's assume that the SAME problem with log can actually produce two DIFFERENT types of bricking. There may be several causes (or maybe tens of them), completely unrelated to the "log at 320" one, that may cause the bricking. We have now evidence, after more than one year from the initial reports and published solution, that a number of drives manufactured in various factories AND NOT manufactured in the originally given timeframe, AND also of different model/revision can (and have ) bricked themselves. So there may be MORE reasons than the original one. The opposite thing is happening now, the solutions provided by this thread - meant to ONLY fix the original issue - are seen by everyone with a failed hard disk as a "miracle cure for everything", it is NOT the case. Replacing the firmware with a new version is pretty much pointless, as I see it, I guess I need to explain this part in detail. IF the original firmware is buggy (re:320 log) AND it is the cause for the bricking THEN, assumed that the new firmware is NOT buggy (re:320 log), it DOES make sense to update it. but on the other hand: IF the original firmware is buggy (re:320 log) AND it is the cause for the bricking THEN, the worst thing that can happen to you is the need (since you have now the tools and the knowledge) to re-unbrick it every 6 months to 1 year. There is ANOTHER possibility: There are MANY causes for the bricking, not necessarily linked to a given firmware, and the solutions given in this thread may TEMPORARILY cure them, but since the reason is NOT ALWAYS firmware related, updating the firmware WON'T DO anything that prevents the bricking to re-occur. As I see it, once a drive has bricked, the right thing to do is: unbrick it salvage the DATA on it EITHER: RMA it and get a new one (if still under warranty) throw the drive in the dustbin use it (either the original one fixed or the re-furbished/new one) for a low-low risk backup (like second or third backup copy - and yes, you NEED AT LEAST 2 (TWO) backup copies on different media of any DATA that is worth anything to you) IMHO, people thinking to: use it as "main" drive use it as "only" storage No matter if with the old or new firmware, are playing with fire, and it is statistically evident that when playing with fire burns happen more often than when playing with sand or mud. jaclaz

Everything seems to lead that "something else" besides the .inf is needed when installing a "hardware" driver. This could be the "right" solution: http://nsis.sourceforge.net/InstDrv_plug-in the NSIS installer is competely free. I am attaching a quickly put together thingy, that works for me, obviously it will need to be refined and polished, but it seems like working. jaclaz QEMUTAPNSIS.zip

It looks a lot like an SMAJ5.0A http://www.vishay.com/doc?88390 http://www.littelfuse.com/products/TVS+Diodes/Surface+Mount/SMAJ/SMAJ5.0A.html jaclaz

Are you sure? If the partiion is created (even if not formatted) a drive letter should be assigned to it, otherwise FORMAT could not work. jaclaz

Most probably yes, but it's difficult to say. Unless I am mistaken, you have posted "Side B" of the burned PCB and "Side A" of the "replacement one". Since my crystal ball is again in the shop for tuning , I have to use I-CHING, that tell me: The weak element is above, the strong below; hence their powers attract each other, in your case the weak element is the PCB and the strong one is the HD, the general meaning is that you are doomed to success, but the road to reach it will not be easy. jaclaz

You are welcome. As you can see from my previous post, it is not that XOSL is in any way "not as stable as grub4dos". XOSL simply relies on bootsectors. grub4dos can, besides relying on them, BYPASS them. In other words, grub4dos can use BOTH (example): title WinPE on (hd0,7) BOOTMGR hide (hd0,0) hide (hd0,1) hide (hd0,2) hide (hd0,4) hide (hd0,5) hide (hd0,6) root (hd0,7) chainloader /bootmgr And: title WinPE on (hd0,7) bootsector hide (hd0,0) hide (hd0,1) hide (hd0,2) hide (hd0,4) hide (hd0,5) hide (hd0,6) root (hd0,7) chainloader +1 The latter (unless you correct the sectors before) won't work exactly as XOSL won't, the first simply ignores the BPB of the bootsector and directly loads the Systemfile. jaclaz

It would be interesting to know how you would make a logical volume inside extended Active.... Quick sum up: the Active flag is used by "standard" MBR code to choose WHICH partition among the 4 (four) entries in the MBR Partition Table to boot from a logical volume inside extended it is NOT in one of the entries in the MBR partition table you need a kind of bootmanager to chainload the bootsector of a logical volume inside extended the "standard" code in the bootsector or PBR won't normally work unless you fix the "sectors before" parameter in the BPB of the bootsector (see already given link) the alternative is bypassing the bootsector and directly chainloading the system file (grub4dos can do this) Normal boot sequence: BIOS->MBR->PBR or bootsector of Active Primary partition->Systemfile invoked by bootsector (IO.SYS or NTLDR or BOOTMGR, etc.) Boot sequence with most bootmanagers: BIOS->MBR->Bootmanager->PBR or bootsector of ANY partition->(FAIL if BPB is wrong)->Systemfile invoked by bootsector Possible bootsequence with grub4dos (I think newish syslinux/isolinux can do the same): BIOS->MBR->grub4dos->Systemfile on ANY partition jaclaz

Ok, found the problem with devcon.exe. You need to change this: ;---------------------------------------------------------------- ; Manufacturer + Product Section (Done) ;---------------------------------------------------------------- [Manufacturer] %Provider% = tap08qemu [tap08qemu] %DeviceDescription% = tap08qemu.ndi, tap08qemu to this: [Manufacturer] %Provider% = tap08qemu [Models] ; Note 1. Replace the bogus *NM_OFDRIVER "hw-id" with a real hardware PnP ID ; Note 2. Optionally, add more NIC models supported by this file ; ; DisplayName Section hw-id ; ----------- ------- ------ ;%DeviceDescription%=*yourdriver.ndi, *NM_OFDRIVER [tap08qemu] %DeviceDescription% = tap08qemu.ndi, *QEMU_TAP then devcon.exe install oemwin2k.inf *QEMU_TAP works for me (don't ask which is the trick, as I don't know). Just got tapinstall.exe from OpenVPN, which I think it is not redistributable as well (but check it's status - I am not at all sure of this ). And I can confirm that: tapinstall.exe install oemwin2k.inf *QEMU_TAP works allright with the modified .inf. I'll see if I can find anythng else. jaclaz P.S.: Found an interesting link: http://forum.installsite.net/index.php?showtopic=15898 it seems like the most "plain" way is to create a DIFX package using DPINST, which is redistributable.

No. The devcon.exe doesn't work for me (XP SP2). C:\Downloaded\tapdriver\TAPDriver\i386>devcon.exe install oemwin2k.inf t ap08qemu.sys Device node created. Install is complete when drivers are updated... Updating drivers for tap08qemu.sys from C:\Downloaded\tapdriver\TAPDriver\i386\oemwin2k.inf. devcon.exe failed. It starts installing but then fails, it seems like there is the need for some other files beside the .sys, or maybe it doesn't "connect" properly to the virtual device. In the .inf there are additional files "REMmed out" by using ; . Among the Remmed ones there is the "right" way (supposedly) to install this service, which is running tapinstall.exe, which seems like being a file coming with OpenVPN, which should be an equivalent to devcon.exe. here is a partial output of devcon listclass NET with bolded the devices installed in various attempts. Something possibly very easy to fix must have been overlooked or it is missing. jaclaz

No, but the method should work. Please post how you succeed to install it with devcon.exe, and I'll try to make a "working" .inf for it. (I need to understand how it behaves when succesfully installed) jaclaz

There is already a rather known project called Qemu Manager, if I may, you should change slightly the name of your project to avoid confusion. Hey, wait, the link is on daveryn.co.uk, which is the home of the Qemu Manager! So you're Dave! Welcome to MSFN, happy to meet you. Back to your problem. Cannot you use a .inf file? The linked file has one. I am not an expert at all in using them, but if I managed to put together an install of a service: http://www.boot-land.net/forums/index.php?showtopic=9765 you can do it as well. Basically: RunDll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 <your_driver>.inf and you need a DefaultInstall section in the actual <your_driver>.inf Just post if you need further help, if you better explain what the driver is for, I can try modifying the .inf and test it. jaclaz

Just for the record, there is a way to "embed" a diskpart.txt file inside a batch, here: http://www.msfn.org/board/index.php?showtopic=126069&st=16 http://www.msfn.org/board/index.php?showtopic=126069&st=19 jaclaz

Actually there is NO difference in the .lst files at a binary level. I guess that we can put the blame on (choose one) of the things that may have had an hiccup: nlite magiciso you WinsetupfromUSB Actualy I would exclude #4 (and I presume ilko_t would do the same) , and you'll probably want to exclude number #3 , then, since it seems like in this particular case MagicISO appears "innocent" , considered that nuhi is not often around here anymore, I would say it was a nlite hiccup, and live happily forever.... jaclaz