Can't boot - "autochk program not found - skipping autocheck" after XP SP3

There should always be a reboot between uninstall and reinstall of the same thing in Windows, and after installing another reboot to see if it works ok.
 
Specimen

I have done all the steps including rebooting Windows after each step - the only thing you can not do is remove Parallels Tools via Windows's Add/Remove Program.

Prior to starting Parallels all was fine (w/r to Boot Camp) - I started Parallels, cleared the tools and then installed them again.

AND THE PROBLEM CAME BACK!!!! Parallels runs fine but Boot Camp can no longer boot.

This really is getting ridiculous! I've invested over 15 hours all told (3 of them was repeating the procedures tonight).

Bob
 
Try very simple way to exclude Parallels Desktop affection
1. Uninstall Parallels Desktop as described in http://kb.parallels.com/en/4790
(do not install back)
2. Repair Windows partition
3. Delete Boot Camp Folder from Documents/Parallels
(or whatever your Boot Camp VM is called)
4. Delete /Library/Parallels folder (not one in you home profile but in Mac HD)
5. Perform Windows repair,
Make sure you can boot natively in Windows.
6. Install Parallels Desktop , create Boot Camp VM

Note, if you upgraded from PD 2.5 you need to have old key also to activate newly installed Parallels Desktop
 
smudge said:
I couldn't wait any longer so I tried some of the suggestions and now it is working perfectly. Here is what I did.

Boot into Parallels and uninstalled SP3
Boot into native Windows via BootCamp
Downloaded and installed Bootcamp 2.1 Update, reboot
Installed Windows SP3 Update, reboot
Installed a few other patches/updates via Windows Update, shutdown.
Boot into OSX and started Parallels
Tried booting the Bootcamp partition but got the autochk error. Swore out loud startling the sleeping dog.
Cleared the Parallels info from the bootcamp partition via the Parallels Configuration Editor.
Started Windows in Parallels, no errors.

Just to be sure, rebooted into native Windows again. No errors.
Just to be more sure, rebooted into OSX, ran Parallels, launched Windows.

SUCCESS!

So it seems to be a problem with the Parallels info on the Bootcamp partition before SP3 and/or BootCamp 2.1. After uninstalling/reinstalling SP3/BC2.1 then removing Parallels info and letting it reinstall the info on the next install fixed the autochk error.

Hope this helps the developers and users.
Click to expand...

I'd like to see Parallels include something like this as a KB article as well. This is the scenario that resolved my problem without the need to do a repair installation. My scenario:

Starting point:

Hardware: MBP 2.4GHz 4GB RAM
Software: Leopard, WinXP SP2, BootCamp 2.1, Parallels 5608
Installed SP3 from within Parallels
result: WinXP SP3 booted fine inside of Parallels, got autochk error using boot camp

History of system:
started as Tiger using BootCamp 1.x beta
Upgraded Parallels some quite a while ago to a leopard-compatible version
upgraded from Tiger to Leopard
Upgraded Parallels several times
Upgraded Parallels to 5608
upgraded boot camp to 2.0 from Leopard install DVD
upgraded boot camp to 2.1 from Apple download
install SP3 from within Parallels

Solution:
followed smudge's directions, minus the swearing because I expected it based on his post.

I did need to re-activate windows, so hopefully this isn't using a "real" activation -- I won't really know for a while because this XP install is from an MSDN kit, which has 10 activations for different hardware.

Note that in the past, I've always installed MS updates from within Parallels and not from within bootcamp (this was my first time in bootcamp in about a year, but I wanted to verify functionality after installing SP3).
 
TimeLordBob said:
Specimen

I have done all the steps including rebooting Windows after each step - the only thing you can not do is remove Parallels Tools via Windows's Add/Remove Program.

Prior to starting Parallels all was fine (w/r to Boot Camp) - I started Parallels, cleared the tools and then installed them again.

AND THE PROBLEM CAME BACK!!!! Parallels runs fine but Boot Camp can no longer boot.

This really is getting ridiculous! I've invested over 15 hours all told (3 of them was repeating the procedures tonight).

Bob
Click to expand...

Bob, Specimen,
I have also followed the exact steps in KB 5447 and end up in the same situation as Bob !!! Parallels runs fine but native Boot Camp can no longer boot.

Clearly KB 5447 is not sufficient!!! Once you finish steps (10) "navigate to PD Configuration Editor -> Hard disk 1 -> Advanced and click 'Clear' to remove Parallels Desktop information from Boot Camp" and step (11) "StartVirtual Machine and reinstall Parallels Tools"; the native Boot Camp XP-SP3 environment is corrupted again and it will not reboot under BC !!!

I have entered my details as Parallel's User Problem Ticket #585060 but the only response I have gotten from Parallel's is that KB 5447 is the corrective procedure. They do not acknowledge KB 5447 is an infinite waist-of-time loop in certain user environments!!!

Krel
 
John@Parallels said:
Was someone followed my suggested procedure?
Click to expand...

So John@Parallels,

Are you saying KB 5447 needs to be augmented to also require a comprehensive Uninstall of Parallels Desktop as described in http://kb.parallels.com/en/4790 as one of the intermediate steps??

You post #145 on this thread is not at all understandable as to where in the 11 point sequence of KB5447 your steps should be done. Can you please post the complete modified sequence of KB 5447 that incorporates your recommendations??


KB 5447.b (your version) describes how to correct an already broken BC partition. Can you please provide the proper sequence of detailed steps that should be taken to update a working dual boot Parallels/BC XP-SP2 partition to SP3?? (This is the information Parrallel's should have provided as a Technical Bulletin or a section in the build-3.0.568 Release Notes so those of us who are trying to run a business would not have waisted almost 20 man-hours. Some of us are not Beta testers and therefore expect your product work as described in your product literature. If support for upgrading to SP3 was such a troublesome feature, your release notes should at least have outlined the procedures. I cannot believe you QA team is so poor as to not have attempted this SP3 upgrade scenario; they must have encountered this problem themselves.)

Thanks in advance for your efforts,
Krel
 
Basically what I am suggesting is to reinstall Parallels Desktop is to remove /Library/Parallels folder in order to remove hidden Boot Camp files using by Parallels Desktop,
I suppose only that information in that folder is corrupted thus causing Boot Camp crash.
In any way it is not modified steps, just additional steps in order to make sure nothing affects Boot Camp, if it still fails, thus something is on Boot Camp side not on Parallels Desktop
 
John@Parallels said:
Basically what I am suggesting is to reinstall Parallels Desktop is to remove /Library/Parallels folder in order to remove hidden Boot Camp files using by Parallels Desktop,
I suppose only that information in that folder is corrupted thus causing Boot Camp crash.
In any way it is not modified steps, just additional steps in order to make sure nothing affects Boot Camp, if it still fails, thus something is on Boot Camp side not on Parallels Desktop
Click to expand...

Thanks John@Parallels for your reply,
I may try it out the next time I have an additional 2 hours to kill (after the ~20 I have already waisted!!).

However, your response troubles me for the following reasons (hopefully you simply misspoke):

1) You state you are in fact adding "just additional steps" to KB 5447 and yet you are not recognizing this as a significant modification to KB 5447. If you work for Parrallel's, can you please liaison with them to amend KB 5447.

2) Your logic asserting "if it still fails, thus something is on Boot Camp side not on Parallels Desktop" is flawed. Your amended procedures results in a complete removal of Parallels Desktop (including any remaining hidden files) and a verification of a functioning native BC XP-SP3 re-boot before Parallels Desktop is re-installed. If a final re-boot of the native BC XP-SP3 again fails, it should be obvious the re-installation of Parrallels Desktop has broken a previously working BC XP-SP3; instead you state something is wrong with BC because it can no longer natively reboot with PD installed.

Thanks for your efforts,
Krel
 
If final reboot in Boot Camp Windows fails, it means something is corrupted in Boot Camp, because of incorrect Windows update through Parallels Desktop instead of Boot Camp
KB if you check earlier in thread was published by me, but I cannot see any reason for now, to add this step, as in case of those files corruption, it means Mac OS corruption too, because we assume that Windows in Parallels desktop is working
 
John@Parallels said:
If final reboot in Boot Camp Windows fails, it means something is corrupted in Boot Camp, because of incorrect Windows update through Parallels Desktop instead of Boot Camp
KB if you check earlier in thread was published by me, but I cannot see any reason for now, to add this step, as in case of those files corruption, it means Mac OS corruption too, because we assume that Windows in Parallels desktop is working
Click to expand...

John@Parallels,

The following is an excerpt of my User Problem Ticket #585060.

----------------------------------

Query category: Unexpected Windows XP Professional behavior
Product: Parallels Desktop for Mac 3.x
Build number: 5608
Host OS: Mac OS X 10.5.x Leopard
Host OS details: BootCamp 2.1
Guest OS/Remote OS: Windows XP Professional
Guest OS/Remote OS details: XP3
Guest OS amount of memory: 1.2GB
Type of computer: MacBook Pro
Computer RAM: 2 - 4GB
Description: Per KB Article ID 5447 :

Sequence:
0) Start with bootup XP Pro SP2 BootCamp
1) Upd BootCamp to 2.1
2) Upd XP Pro to SP3 via BootCamp
3) Test reboot of BootCamp: OK
4) Boot MacOS
5) Clear Parrellels Disk Info for BootCamp partition, 5) boot Parallels
6) re-install Parralels Tools
7) Test reboot Paralles: OK
8) Boot native BootCamp: get `Autochk not found -- skipping autochk` error in infinite reboot loop!!!!

-------------------

As can be seen from the description, I started with a working BC XP-SP2 dual boot configuration with PD build 5608 already installed. The SP3 update was done under BC, not PD.

Your amendments to KB 5447 in effect states that

1) PD Parallels Tools should be completely removed from BC and that PD should also be completely removed from Leopard prior to updating BC to v2.1.
2) PD should be re-installed after BC has been updated to SP3 via BC.

I will try this variation of KB 5447 when I can afford (literally) to lose another 2 hours.

Thanks,
Krel
 
Well, I suppose some additional details will help:
1. We put files in Boot Camp OS, when PD VM starts
2. We remove files when VM is correctly shut down
3. In case SP3 upgrade through Parallels , some core files in Windows are modified but registry entries no
4. If you can properly shutdown VM, no files ae left from Parallels in Boot Camp
Thus there is no problem when you uninstall Parallels Desktop
5. When you update Boor Camp VM to SP3 correctly, Parallels DEsktop detects registry changes and recreate new configuration

Summon:
1. I recommended to uninstall Parallels to avoid effect of corrupted Mac OS side and to proof that corruption is on Boot Camp side

2. If you believe that Mac OS and Boot Camp by itself are ok, no need to uninstall Parallels Desktop,
Article helped in about 100% cases.
 
John@Parallels said:
Well, I suppose some additional details will help:
1. We put files in Boot Camp OS, when PD VM starts
2. We remove files when VM is correctly shut down
3. In case SP3 upgrade through Parallels , some core files in Windows are modified but registry entries no
4. If you can properly shutdown VM, no files ae left from Parallels in Boot Camp
Thus there is no problem when you uninstall Parallels Desktop
5. When you update Boor Camp VM to SP3 correctly, Parallels DEsktop detects registry changes and recreate new configuration

Summon:
1. I recommended to uninstall Parallels to avoid effect of corrupted Mac OS side and to proof that corruption is on Boot Camp side

2. If you believe that Mac OS and Boot Camp by itself are ok, no need to uninstall Parallels Desktop,
Article helped in about 100% cases.
Click to expand...

John@Parallels,

From what I can tell from this thread, the following list of users are still in exactly my same situation (in certain cases some had attempted to erroneously update to SP3 via PD VM and other cases via the correct native BC). KB 5447 has left them stranded in an infinite waist-of-time loop. The poor user "Levent Colak" actually tried to apply KB 5447 three times in a row and it finally mysteriously worked for him, he thinks because on his last attempt he happened to perform many consecutive PD VM reboots prior to his final reboot of native BC.

Krel, zoozie, jakoban , Cocoa Beast, TimeLordBob , pkasin , ....

I think a more accurate statement would be to claim KB 5447 helped in about 99% of the cases! Some users said they gave up and were moving on to VMWare.

Krel
 
Let us clarify, the first thing we need to confirm, that Window in Boot Camp is working after repair and update to Boot Camp 2.1, if it is working there will be no problem in Parallels Desktop, Do not start Parallels Desktop until you can see that Boot Camp Windows is working
 
John@Parallels said:
Let us clarify, the first thing we need to confirm, that Window in Boot Camp is working after repair and update to Boot Camp 2.1, if it is working there will be no problem in Parallels Desktop, Do not start Parallels Desktop until you can see that Boot Camp Windows is working
Click to expand...

John@Parallels,

I had already provided you the details of my testing in the excerpt of my User Problem Ticket #585060 that explicitly confirms the detailed testing/retesting of the various boot scenarios. This "first thing we need to confirm" is precisely what I, and apparently others, have already done when applying KB 4557! (Telling me to do it again but be careful to test a reboot after each major step doesn't make me feel any more confident you have acknowledged there is a problem with KB 4557.)

On the other hand, your additional recommended steps to KB 5447, requiring a prior complete removal of PD, thus eliminating the possibility of a subtly corrupted PD installation somehow affecting the upgrade to BC 2.1 and/or SP3, seems to be a reasonable suggestion.


As I already said, when I can afford to lose another 2 hours of my billable time (in addition to the ~20 I have have already lost) I will give your amended KB 4557 procedure a try.

On the other hand, maybe I should be using those 2 hours to evaluate VMWare instead as the other malcontent users are doing!

Thanks,
Krel
 
Still no resolution to Parallels corruption of BootCamp??

I last checked this thread over two weeks ago. My BootCamp partition still won't boot. It worked fine after updating to SP3 (done from natively running Windows via BootCamp 2.1).

It's VERY DISTURBING that the conversation hasn't progressed at all, and that Parallels refuses to even believe that there is a problem. Native booting via BootCamp was fine until I ran Parallels, got the boot error, cleared the Parallels info on the hard drive making Windows bootable via Parallels, and then found that I can no longer natively boot via BootCamp. There is ZERO doubt that the problem is introduced by Parallels, and even John admits that Parallels is modifying the BootCamp partition when running in virtual mode. Jeez just a tool to reset the BootCamp parameters your software messes with to a native BootCamp-bootable state for SP3 would be helpful, even if it obliterates some settings in the process. Can it be that difficult? Is there some machine-specific information that Parallels saves somewhere to be swapped back onto the BootCamp partition in order to make native booting work again? If so more information would be helpful. If I'm going to have to debug the problem on my own, I really don't like being left in the dark about what gyrations Parallels is doing.

I'm giving it a couple more weeks to hear of some progress toward a solution that doesn't require 12 hours of my time reinstalling -- and a little Voodoo, complete with the secret dance. If Parallels still doesn't believe that a problem even exists, I'm shifting all the working machines in my company to VMWare. I'm not trying to be vindictive -- I've been very happy with Parallels up to now. But as long as you insist there's no problem, I have no way to be sure it won't happen again next week, even if a reinstall fixes the problem.

Sorry so blunt, but the ONLY attraction of Parallels or VMWare is that is lets me get work done via XP.
 
Wait,
Parallels doesn't modify Boot Camp, we put our files in order not to affect real Boot Camp - not Parallels modifies Boot Camp - it is the big difference,
Windows repair removes those files , and if Windows still cannot startup normally through Boot Camp, problem is on Windows side - as I could see through this thread - noone had problem after repair to boot directly in Boot Camp
From the other hand, my recommendation to remove Parallels Desktop and files is step to make sure that files Parallels is using are not corrupted and thus not affecting anyway Boot Camp.
and
 
John@Parallels said:
Wait,
Parallels doesn't modify Boot Camp, we put our files in order not to affect real Boot Camp - not Parallels modifies Boot Camp - it is the big difference,
Windows repair removes those files , and if Windows still cannot startup normally through Boot Camp, problem is on Windows side - as I could see through this thread - noone had problem after repair to boot directly in Boot Camp
From the other hand, my recommendation to remove Parallels Desktop and files is step to make sure that files Parallels is using are not corrupted and thus not affecting anyway Boot Camp.
and
Click to expand...

John@Parallels,

Regarding your quote "as I could see through this thread - noone had problem after repair to boot directly in Boot Camp":

As has been repeated many times in multiple posts, the Windows Repair step does work and BC can do a native reboot properly again after the repair. The problem is that after steps #10 and #11 of KB 4557, a native reboot of BC no longer works again!!!!!!!!!!!!

How many times does a subset of your user community need to tell you KB5447 does not work for them!!!!!!!!!!
As the users zoozie, jakoban , Cocoa Beast, TimeLordBob , pkasin, ... etc... have all been telling you, KB 5447 leaves them back were they initially started many hours before with the error 'Autochk not found -- skipping autochk' all over again when finally rebooting the native BC!!!!!!!

You either need glasses or need to re-learn how to understand what you read !!!! I now have severe doubts you have been able to understand the gist of our earlier posts (e,g. you still believe KB 5447 has resolved the problem for "100% of the cases"). Repeating things again to you will not make any difference, it is up to you to make the effort to understand and believe the technical details we (the group of users who are having problems with KB 5447) are stating in our posts.

Regarding further testing of your amended KB 5447 procedures:

Your suggested additional PD un-install steps to KB 5447 seem reasonable and maybe one of these other guys is willing to to try it out. I can no longer afford to Alpha-Test this for you since I am on a fixed-fee contract which has terminated.

Since the PD un-install sequence, along with the other consequences of KB 5447, makes it an unfeasible solution for my customer's IT Dept anyway , I have completed my report to them stating they cannot reliably use the latest production PD release (build 5608) to upgrade their 22 MacBook Pro dual-boot notebooks from BC XP-SP2 to BC XP-SP3. They have agreed to contract me to evaluate VMWare as an alternative upgrade for them. (I still hope your next PD release will correct this problem and be available in time to meet their schedules.)

(Personal Note> I don't believe Parallels QA or Customer Support is so myopic or full of hubris that they refuse to acknowledge there is a problem here. I have never seen this behavior before from Parallels and it just doesn't make any business sense at all!!! Some friendly advice to you John@Parallels, and I do mean this sincerely; I recommend you have a Supervisor or Product Manager from Parallels look at this thread to explain what is going on here to you. You don't want this situation get out of hand and blow up in your face further down the road.)

Thanks for all your efforts despite the confusion you seem to be in,

Krel
 
You must log in or register to reply here.
Back
Top