Jump to content











Photo
- - - - -

"Autochk program not found" when installing Windows 7


  • Please log in to reply
6 replies to this topic

#1 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 778 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 04 August 2015 - 03:31 AM

I got this error 3 times last night when trying to finish 7 install. My ISO is Microsoft-issued, verified with MSDN hashes. It works fine in VMware Workstation and VirtualBox. I did check and the autochk exe is found in C:\Windows (can't remember which subfolder, if any).

 

I tried installing from burned disc, USB, as well as from a NTFS partition with setup files stored there (using a FAT32 USB to bootstrap into UEFI mode).  I also tried mounting the ISO in my Zalman VE 400. UEFI DUET was used, which I suspect isn't the issue.

 

I also tried creating all my partitions on both of my drives in advance, with the first SSD target disk containing only a FAT32 EFI volume and a 2nd NTFS volume for 7.

 

I tried both installing from imagex and bcdboot, as well as from the official GUI setup, after deleting all partitions and the partition tables from both disks. When using the GUI, setup reaches the end just before reboot, and says that the install couldn't be completed.

 

Strangely enough, I got this exact same error when restoring from official Alienware recovery discs, which will only restore in BIOS/MBR mode.

 

This thread is basically a continuation of my previous "Windows installation repeatedly fails to complete", but because I now have a very specific error and can't determine the cause, I started this topic. I no longer suspect my RAM to be the issue, or my drives, both of whose SMART data checks out fine, and both drives being relatively new (bought in the past 120 days).

 

I also noticed that no pagefile.sys or hiberfil.sys is ever created during install, by either the GUI or when using ImageX.



#2 cdob

cdob

    Gold Member

  • Expert
  • 1459 posts

Posted 04 August 2015 - 04:17 AM

I no longer suspect my RAM to be the issue, or my drives, both of whose SMART data checks out fine, and both drives being relatively new (bought in the past 120 days).

Compare SMART data UDMA error rate since last time. Did they increase?
They should not increase given good hardware: controller cable case.

#3 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 778 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 04 August 2015 - 04:47 AM

I'll compare it in the next few hours,although I'm certain the error count has gone up. I've been trying to switch back and forth repeatedly between data and data modes by flashing different bioses, as described in my previous thread, but data has been somewhat unstable because, from my understanding, there was an issue in the early SATA controllers with my model. Later revisions of my model had the issue fixed, with something called "B3 stepping", which mine has. But despite that many owners of my model still report instability when using sata3. The general idea is to get the max speed from my SSD.

 

For the past few weeks I've been using a bios that limits SATA speeds to 2, as Dell had intended as a partial counterfix to the problem. But this autochk thing still comes up.

 

Are new sata cables manufactured for laptops? As well as sata controllers? Are they easy to replace?



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15386 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 August 2015 - 09:26 AM

No, you don't want to even THINK replacing a SATA controller on a motherboard.

 

And yes of course there are cable spare parts, but I believe you won't like the price tag  :ph34r: (examples):

http://computers-par...47-p-40144.html

http://www.impactcom....com/v9p47.html

http://www.parts-peo...n=item&id=11421

 

:duff:

Wonko



#5 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 778 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 04 August 2015 - 09:42 AM

@ Wonko: The highest-priced cable you listed is around $55. A bit steep, but if it fixes my issues, then it means I've finally found the source, and well worth the cost of not having more headaches and continually reinstalling Windows again and again.

 

But before I order anything, is there a way to prove my current SATA cable is defective? Like, with actual tests, not just conjecture and hypotheses. I'd rather not order anything if the cable I have is perfectly fine. I found your listings earlier when I was searching around (before you posted).

 

If the issue is the SATA controller rather than the cable, then a new cable wont help. I suppose a technician would charge a steep price to replace the controller. Or simply refuse to do it.

 

I'm very nearly ready to murder the Asian guy that sold me this laptop, because he probably knew it had issues. If I sell something I always disclose all known issues.

 

Edit: New problem. I deleted all partitions from the SSD, and zeroed out the partition table. Then I booted into a physical, freshly burned disc, used 'clean' command in disk part, and created a primary NTFS volume, formatted it, and marked as active. Intended partition table is BIOS/MBR, not using native UEFI or DUET. The first portion of setup completes, then it reboots to finish up. But it never gets to that point, error "bootmgr is missing" appears. It definitely sounds like something is causing data to be corrupted as it is written. A new SATA cable is the only thing I haven't tried.



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15386 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 August 2015 - 12:14 PM

Well, I would first check if BOOTMGR actually exists.
Then I would check if -for any reason- you have invalid data in the PBR (or VBR or $Boot) of that partition/volume.

About the cable, check this:
http://www.msfn.org/...atapi-event-11/
No way in practice to test it.

If I get it right, from the amount of issues reported (not only by you):
http://forum.noteboo...m14x-r1.672655/
http://forum.techinf...8-sata-fix.html
http://forum.techinf...ios-issues.html
http://en.community....3746/t/19410854
all in all you have a defective (BORN defective in the sense of evidently not designed well enough or compatible enough with SSD's) piece of hardware, that due to it's instability the good DELL (or Alienware or BOTH) guys seemingly failed to properly "fix" downgrading instead the firmware (or *whatever*) to SATA 2 instead.

The referenced threads (and some others I have seen around) seem like hinting that there are also issue connected with the actual make/model of SSD and more generally it's like some (black) magic :wodoo:  applies as most reports are about the non repeatability of successes (or failures) by different people, it is also possible that there are slight differences in production batches (of the motherboard) connected to these "random" results and reports.  :ph34r:

No, I don't think - at first sight - that in this case it is the cable, there are too many *crazy* other possibilities, if it was a desktop trying a new SATA cable (at virtually no cost) would have made sense, but given the records of scarce reliability of that particular laptop with SSD's it is improbable that the root cause is the cable.
I would rather try a (known to be good) conventional hard disk and if it gives no issue then the cable is OK.

:duff:
Wonko



#7 Zoso

Zoso

    Silver Member

  • Advanced user
  • 640 posts
  •  
    Isle of Man

Posted 04 August 2015 - 01:19 PM

hi AnonVendetta, Wonko,

in the past when booting a universal XP clone on different USB sticks I have ran into the same error.

IIRC the problem was either from cross-linked (inadvertently) XP versions on different partitions (in my case solved by using encryption to make the different XP's not see each other) OR incorrect partitioning due to incorrectly setting up extended partitions for booting.

IMO it is essentially a type of disc read error. it cant find autochk for what ever reason.

edit: in your case I would investigate the format further. check partition types with mbrwiz and other tools to compare them and see if they agree. (ive had conflicting results in the past where windows said a partition was NTFS but mbrwhiz reported fat16) and maybe try different tools to format with.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users