Error with syspreped windows 7 image related to capisp.dll execution... RRS feed

  • Question

  • Hi Folks,

    some time ago I crafted an windows 7 image with sysprep generalization for WDS deployment. In real there are 2 images: one dumped w/o sysprep and the another w/ (dumping with ImageX Tool from WAIK for W7/W2K8R2). The syspreped one I delivered to our WDS Server. In the past I made several changes based on the non-syspreped image (incl. WUs) and afterward I've generated a new syspreped version from it. ...and now, since the last revision und sysprep run the last syspreped version (stored at the WDS) is no longer installable onto any target machine... Ervery time I tried to deploy this version from the WDS at the target machine an error popup occurs and says that this image cannot be installed at this target machine type (see *** - the german message). Examinig the SETUPACT.LOG / SETUPERR.LOG files the following problem has been stated:

    2010-06-21 14:22:54, Info       [0x0f0081] SYSPRP LaunchDll:Successfully executed 'C:\Windows\System32\sppnp.dll,Sysprep_Specialize_Pnp' without error
    2010-06-21 14:22:54, Info       [0x0f008b] SYSPRP RunRegistryDlls:Found entrypoint in registry at SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\SysPrep\Specialize\{2172c981-2c23-e969-b30d-046ffeeb096e}; will try to launch 'C:\Windows\system32\capisp.dll,CryptoSysPrep_Specialize'
    2010-06-21 14:22:54, Info       [0x0f0080] SYSPRP LaunchDll:Found 'C:\Windows\system32\capisp.dll,CryptoSysPrep_Specialize'; executing it
    2010-06-21 14:22:54, Info                         capisp.dll::CheckIFCryptoSysPrepSpecialized: returning 0
    2010-06-21 14:22:55, Info                         capisp.dll::CryptoSysPrep_Specialize: assigned CAPI machine guid "44d42aa2-dee4-4023-bea5-d2f166bbb42c"
    2010-06-21 14:22:55, Info                         capisp.dll::DisableAdministratorIfApplicable disabled the admin account.
    2010-06-21 14:22:55, Info                         capisp.dll::CryptoSysPrep_Specialize: returning 5
    2010-06-21 14:22:55, Error      [0x0f0082] SYSPRP LaunchDll:Failure occurred while executing 'C:\Windows\system32\capisp.dll,CryptoSysPrep_Specialize', returned error code 5[gle=0x000003e5]
    2010-06-21 14:22:55, Info                  IBS    Callback_Specialize: Internal Providers Specialized Failed. System can't proceed to handle Internal Providers
    2010-06-21 14:22:55, Info                  IBS    Callback_Specialize: Specialize return: [5]
    2010-06-21 14:22:55, Error      [0x060435] IBS    Callback_Specialize: An error occurred while either deciding if we need to specialize or while specializing; dwRet = 0x5
    2010-06-21 14:22:55, Info       [0x0640ae] IBSLIB PublishMessage: Publishing message [***Windows kann nicht für die Ausführung auf der Hardware dieses Computers konfiguriert werden.]

    The mentioned error is the only one.

    ANY help is very appreciated!

    From Colonel Gizmo

    Wednesday, June 23, 2010 3:17 PM

All replies

  • Hi,


    Regarding the returned error code, error code 0x5 is a “Access denied” error. It seems that the sysprep disables the administrator account, it can’t process the capisp.dll and pass CryptoSysPrep_Specialize. To resolve this kind of issue, I would like to suggest:


    1.        Ensure that you deploy image running as Administrator account.

    2.        Mount the image and check if the capisp.dll file exists and try taking ownership of it.

    3.        Open Registry Editor and navigate to the following path:




    Check if there is an entry with the Data: C:\Windows\system32\capisp.dll,CryptoSysPrep_Specialize , make sure it is spelled correctly and check the permissions on the above key.


    4.        Then deploy again.


    Best Regards


    Please remember to click “Mark as Answer” on the post that helps you.
    Thursday, June 24, 2010 6:02 AM
  • Hi Dale,

    I've checked the following according your suggestions

    relating to 1.
    -> I run the SysPrep Tools before dumping the Image with ImageX using another local admin account, NOT the builtin Administrator account and deploying the image via WDS using a domain user account with domain admin privileges. This was functioning for the previous and non-erroneous image version(s).

    relating to 2.
    -> I've checked the capisp.dll - it's existing in place and ownership information is TrustedInstaller - this should be ok? Or why you said '...taking ownership of it.'? Local Users group and local Administrators group have read, read&execute permissions on it.

    relating to 3.
    -> All seems to be OK. Below your advised key the entry is present and spelled correctly. The key permissions are the following
    - SYSTEM - FC for this key and subkeys
    - local Administrator group - read value, enlist subkeys, notifications, read control for this key and subkeys
    - local Users group - same as Admins
    Double check these permissions with another system states that this should be ok.

    This what's confusing me is that the only differences between this problematic image and the previous and functioning one is
    - additional windows updates were installed
    - adjustment of maximum registry size via HKLM\System\CurrentControlSet\Control\RegistrySizeLimit (it was set to max DWORD - 0xffffffff)

    Best regards
    Holger Kaßner

    Thursday, June 24, 2010 8:34 AM
  • Colonel_Gizmo,

    Did you ever figure out what was causing that? I am having the same issue under the same circumstances and could not figure out what is causing it. I tried what Dale suggested with no luck.


    Wednesday, September 8, 2010 5:27 PM
  • Any luck yet? I reboot after the SysPrep to test the process, so there is no image creating yet. By default, the permissions match Col. Gizmo, but I've even changed the permissions on the file and key to full control for Admin and System (via UBCD4Win). I have the unattend set to make the Administrator account active, so I'm not sure why the capisp.dll disables the account; however, I've tried the SysPrep without using the unattend and got the same results.

    Here is the log from C:\Windows\Panther\setupact.log:

    2011-01-12 08:15:05, Info       [0x0f008b] SYSPRP RunRegistryDlls:Found entrypoint in registry at SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\SysPrep\Specialize\{2172c981-2c23-e969-b30d-046ffeeb096e}; will try to launch 'C:\Windows\system32\capisp.dll,CryptoSysPrep_Specialize'
    2011-01-12 08:15:05, Info       [0x0f0080] SYSPRP LaunchDll:Found 'C:\Windows\system32\capisp.dll,CryptoSysPrep_Specialize'; executing it
    2011-01-12 08:15:05, Info                         capisp.dll::CheckIFCryptoSysPrepSpecialized: returning 0
    2011-01-12 08:15:06, Info                         capisp.dll::CryptoSysPrep_Specialize: assigned CAPI machine guid "3879d0bc-208c-4c4e-a3a0-0bcfc7b1579f"
    2011-01-12 08:15:06, Info                         capisp.dll::DisableAdministratorIfApplicable disabled the admin account.
    2011-01-12 08:15:06, Info                         capisp.dll::CryptoSysPrep_Specialize: returning 5
    2011-01-12 08:15:06, Error      [0x0f0082] SYSPRP LaunchDll:Failure occurred while executing 'C:\Windows\system32\capisp.dll,CryptoSysPrep_Specialize', returned error code 5[gle=0x000003e5]


    I finally got fed up with trying to fix the problem and ended up just building a new image from a factory image. I thought SteadyState (yes, it works in Win7) may have been causing the error, but the SysPrep worked flawlessly before and after installing the program and configuring it to lock down the machine. I can only assume that prior to Hotfix KB981542 coming out, I changed some settings to make the image work, but these changes hosed the image once the SysPrep was run.

    Good luck everyone!

    Jonathan Hall
    • Edited by Jonathan Hall Wednesday, January 12, 2011 9:28 PM Problem solved with a fresh build
    Wednesday, January 12, 2011 6:25 PM
  • Has anyone found a workable solution to this problem? Same error whether using sysprep /generalize with and without specifying an answer file. Same error deploying to sysprepped image ANY machine, including rebooting the SAME machine sysprep was ran on. Any suggestions...Microsoft?
    Tuesday, August 23, 2011 12:14 AM
  • I may have had several factors causing the problem, but the key for me was disabling Kaspersky's Self Defense prior to sysprepping. Try waiting until after the sysprep to install your AV.
    Tuesday, August 30, 2011 12:06 PM
  • Hi, I am having exactly the same problem.

    I am using Windows 7 Embedded Standard SP1.

    After sysprep /generalize /oobe /shutdown /unattend:unattend.xml

    and rebooting on the SAME machine I get the error message that windows can not be run on this hardware (though it did before). Analysing the log files it is the same error with the capisp.dll.

    Searching several threads here I came up with the idea that a missing <CopyProfile>true</CopyProfile> may be the issue, but also with it no change.

    In the unattend.xml I provide a Administrator account and a user account in the oobeSystem pass. Can it be a problem that there are already user accounts present in the image?

    Also when calling sysprep /generalize /oobe /shutdown (without unattend.xml) I get the same error.

    When deploying the image with imagex /apply WITHOUT sysprep'ing it before it works perfect.

    I am currently really lost and would appreciate any help

    • Edited by scorpion_M Wednesday, April 30, 2014 9:06 AM
    Wednesday, April 30, 2014 9:02 AM
  • For anyone looking I figured out a solution on how to make this work!

    Use shift f10 to open a command window, then type regedit to open the registry editor. 

    Navigate to


    And delete the entry with the following value

    Next, navigate to 


    Decrease SetupPhase by 1

    (These next steps may be optional, I just changed a bunch of values in hopes it would work)

    Navigate to 


    Decrease Cleanupstate and Generalization state by 1

    What this does is set the installation state back a step, and then it skips the CryptoSysPrep_Specialize. The system I tried it on works great so I don't think the step does anything critical. 

    Monday, February 9, 2015 7:43 AM
  • Hello,

    After all the problem was not from Microsoft, it was FOGService. I've disabled it before the sysprep then activate it after.

    When FOGService can reach the FOG server it change the computer name then send a reboot, so sysprep crash.

    Thanks for your help!

    • Proposed as answer by Nicolas Lenain Friday, February 3, 2017 7:06 AM
    Friday, February 3, 2017 7:06 AM
  • Thank you! You saved me a whole world of troubleshooting pain.

    Just had to disable the service auto start before running OOBE phase with 

    sc config FOGService start= disabled

    And later on run have it run the same command to set it back to auto (I simply set it up in RunOnce during OOBE)

    sc config FOGService start= auto

    Saturday, July 18, 2020 12:52 PM