Video Screencast Help

DeployAnywhere error: Platform error calling RegSetValueExw. Insufficient system resources exist...

Created: 08 Jan 2013 | 14 comments

DeployAnywhere error: "Platform error calling RegSetValueExw. Insufficient system resources exist to complete the requested service."

 

This is on a Dell precision T3600, on board Intel C600 storage controller. Evaluates with the success message but stops with the above error halfway through when retargetting for real.

Any ideas? This is the first time we have had a T3600 with the onboard controller, previously we had models with an add in RAID card that worked fine once i added the driver to my ghost winpe boot disc.

Could it be that Ghost does not like the image i have used (my previous t3600 image that has a RAID card)

Comments 14 CommentsJump to latest comment

EdT's picture

Are you deploying a sysprepped image?

What operating system is being deployed?

What version of Ghost?

Have you added the appropriate drivers for your current hard disk chipset to the image?

Did you add Vista 32 bit drivers to WinPE for your new hardware?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

UCLCHEMENG's picture

Not sysprepped

Win7 x64

latest version of ghost

Added the drivers from the Dell website

Yes

UCLCHEMENG's picture

Tried a driver from Intel instead of Dell and still get the same error.

 

Someone MUST know what this error means!

"Platform error calling RegSetValueExw. Insufficient system resources exist to complete the requested service."

EdT's picture

"Latest version of Ghost" is not an answer. Do you have 11.5.1.2266 ?  There are also some later patches which are ONLY available from support if you have one of several specific issues. The patch and contact information for support are in a sticky posting at the top of this forum.

You need Vista 32 bit drivers for the WinPE boot image, but for the DeployAnywhere database you need to ensure you have the correct drivers for Win 7 64 bit.

Have you tried manually building the Win 7 64 bit image on the new hardware with the drivers you have downloaded?  If you are working with drivers or utilities that are not appropriate for your new hardware then this could lead to operating system issues. The error message appears to be related to an API call which could easily originate in an invalid driver.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

UCLCHEMENG's picture

Yes, i have 11.5.1.2266

I will check out those patches, thanks.

I have the 32 bit vista driver and can see the disk in winpe fine, loaded the image on fine, I have the 64 bit drivers in my DADB too, its just the deployanywhere step that fails.

I've tried drivers from Dell and Intel now, I doubt there are any other drivers available. The whole point of DA is so that you dont have to build images from scratch but it looks like I may have to do that now.

 

EdT's picture

DA basically facilitates the creation of an environment in which the plug and play system can load the correct drivers, using the mechanisms within the operating system.

Reading back over the thread, I think I can see what might be going on. You are not using a Sysprepped image. This means that the low level device drivers to access the hard disk are going to be the ones in your original image, and based on the different hard disk architecture on your new machines, are not going to be compatible with it. Plug and Play is an operating system function, but it only comes into play once the basic drivers to read from the hard disk are loaded - this is why during operating system installation you are asked to install any required hard disk drivers before you even get to the main operating system install.

Sysprep provides a method for supporting different block device drivers through the sysprep.inf file - that is the reason you need to use sysprep if you want to support a range of machines.

Consequently, if you wish to avoid using sysprep, you are going to need to recreate a new base image for the latest hardware.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

UCLCHEMENG's picture

Surely the low level drivers used to access the disk would be the WinPE ones and not the ones in my image?

EdT's picture

Yes, that is correct, assuming the issue arises during the "deployment" of the image, and not during the initial boot of the image.

Can I just check one further item - are you continually working with the same piece of equipment?  If you are, is it possible to try with another machine of identical construction?  It would be good to establish whether the hardware is working correctly, as it would not be the first time that someone has spent a lot of time trying to fix a presumed software fault when there was an actual hardware fault affecting deployment.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

UCLCHEMENG's picture

The issue arrises during the deployanywhere command (ghdplyaw32) which is run after the image has been loaded. You type the command in the command window after using Ghost.

I have tried it on two Dell Precision T3600's which were ordered together with identical specifications, so hardware faults should be ruled out.

I returned to this thread because I'm having another similar issue with this model Dell.

Does Ghost not support DeployAnywhere-ing an image that was created on a non RAID setup onto a computer that has a RAID mirror? I'm sure I've done it before but could be wrong.

I might try a later version of WinPE and see if that solves it.

EdT's picture

I am frankly unable to specifically answer your question about whether DA can handle block device drivers as well as plug and play drivers as I have not investigated this aspect, having previously relied on Sysprep to handle the low level drivers required to handle the disk subsystem, as that is the mechanism implemented by Microsoft in their build deployment toolsets.

If you consider how the operating system boots, it is going to need low level drivers correctly configured in order to access the hard disk and commence the loading of the operating system. Once the load process starts, the plug and play subsystems starts scanning the device IDs of every device in the computer, and loading the necessary drivers by searching the INF files for a device ID match. DA is certainly able to provision an image with the necessary driver library to correctly support the plug and pray process and the different mechanisms used in XP and Win 7, but I am uncertain whether this extends to block drivers for the hard disk.

Perhaps one of the more knowledgeable forum members could offer some input here?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

UCLCHEMENG's picture

Reading the notes on the sticky, I dont think the patches are relevant to my problem.

May have to call support.

UCLCHEMENG's picture

I see what you mean, but isnt the purpose of DA to help get around the problem of differing architectures etc? I havent had many problems with DA until now.

The image i was trying to use was from the same model Dell (t3600), but it had a raid controller card. For unknown reasons Dell seem to have started to ship the t3600s without that card now, so thats why i had to DA it. 

After reading your theory this morning, i tried a different image that was built on a different model dell that didnt have a raid card, because it might have been a closer match architecturely, but still no luck.

Last time i looked at sysprep it was a mess, so i'd rather not go that route but i will read up on it again.

For now i am installing windows from scratch! :-(

Thankyou for your suggestions

EdT's picture

Dell basically ship kit based on what they have in stock in their parts warehouse. Unless you have an agreement which defines the exact hardware content, they will stick in anything that meets the overall specification of that model. I expect their supplier of the RAID cards was either late in shipping or they had run out for some other reason.

Sysprep is not actually a mess, but it was a challenge building the sysprep.inf file where you had a large driver library as you had to specify each driver directory separately.

With Windows 7, they have significantly improved the way their plug and pray mechanism looks for drivers, so you just need to specify the parent directory and plug and play will automagically recurse all subfolders in the search for a matching Device ID.

Build 2266 introduces support for the Windows 7 version of Sysprep, so now may be a good time to try again, if you have the time. Otherwise, building a new image is probably the quickest solution.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.