I've created a Win7PE disc which amongst other things has TrueCrypt 7.1 on.

The PE Enviroment boots fine and all applications work fine. The only issue I have is that when I try to mount my laptops System Encrypted drive (Mount Without Pre-Boot Authentication) I receive the following error...

---------- For SEO ----------Error: Cannot set the keyboard layout for TrueCrypt to the standard US keyboard layout.

Note that the password needs to be typed in the pre-boot environment (before Windows starts) where non-Us Windows keyboard layouts are not available. Therefore, the password must always be typed using the standard US Keyboard layout.---------- For SEO ----------

When I started the Win7PE project I set Main Configuration -> System Locale to UK English (being from the UK it seemed a sensible thing to do!) so I flicked it back to "Default", rebuilt the project. The "Default Input Language" is now "English (United States) - US" but I still get the same error in TrueCrypt.

Delving a bit deeper I started SysInternal's ProcMon running and started monitoring TrueCrypt.exe while going though the process to use the "Mount Without Pre-Boot Authentication". ProcMon's log is full of attempts to access the following keys, but the result was always NOT FOUND

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\CTF\TIP\{0000897b-83df-4b96-be07-0fb58b01c4a4}HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\CTF\TIP\{03B5835F-F03C-411B-9CE2-AA23E1171E36}HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\CTF\TIP\{07EB03D6-B001-41DF-9192-BF9B841EE71F}HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\CTF\TIP\{3697C5FA-60DD-4B56-92D4-74A569205C16}and so on...

There are also references to what I assume are the 32bit versions of these registry keys as well, for example...HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CTF\TIP\{0000897b-83df-4b96-be07-0fb58b01c4a4}HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CTF\TIP\{03B5835F-F03C-411B-9CE2-AA23E1171E36}HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CTF\TIP\{07EB03D6-B001-41DF-9192-BF9B841EE71F}HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CTF\TIP\{3697C5FA-60DD-4B56-92D4-74A569205C16}and so on...

As a test I exported everything from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CTF\TIP on my Windows 7 64bit machine to a .REG file and imported it inside a VM machine running my Win7PE but continue to receive the same error when attempting to "Mount Without Pre-Boot Authentication". Going back to my ProcMon log I noticed all attempts to find KBDUS.DLL where failing as well (even though it was in X:\WINDOWS\SYSTEM32) so I copied it the same directory as the TRUECRYPT.EXE which, looking at ProcMon again told my TrueCrypt was finding it but I continued to receive the same error when attempting to "Mount Without Pre-Boot Authentication". Googling I came across something which suggested I needed to copy files from my local C:\Windows\IME to my Win7PE's X:\Windows\IME which again I did (still in VM, manually - not during the build process) which also didn't solve my problem.

I'm sure that my simplistic approach of copying reg keys / files from my PC to a system running Win7PE is probably not the best approach - I was trying to identify the problem and find the solution, before then building an App script to take care of it during the build process.

Its probably worth mentioning at this point that I have used TypeCrypt's Mount Without Pre-Authentication process before under a PartPE disc using Windows XP and PE Builder so I know fundamentally the process works. I'm not sure if the issue is Windows 7 as a whole or because I'm using Windows 7 64bit. If I had a 32bit Windows 7 source I would try it! I need to move to Windows 7 as my XP BartPE disk has driver issues with newer hardware.

I'm not sure where to go from here. Any advice or pointers will be gratefully received!

Note : To reproduce the issue you must click Mount -> Mount Options -> Mount partition using system encryption without pre-boot authentication. Simply going to the System Menu and clicking "Mount Without Pre-Boot Authentication" doesn't make the error come up. It also doesn't allow you mount the drive, it claims the password is wrong. Googling I found a suggestion that if TrueCrypt can't swap to the US keyboard, it just attempts to mount it as an encrypted partition without Pre-Boot Authentication.

This evening I rebuilt my Win7PE project using a Windows 7 32bit source and I was able to mount my laptops encrypted System Drive. Reverting the project back to my Windows 7 64bit source brought the original problem back so I believe this confirms the issue is 64bit Windows 7 based?

With this in mind does anyone have any suggestions on what the root of the problem might be? Is it definitely a True Crypt issue, or could it still be a Windows PE / keyboards issue?

Just a thought - I've checked TrueCrypt on my workstation which is running Windows 7 64bit, and i can attempt to mount encrypted System Drives without receiving the error... so it clearly can work in a 64bit environment, just not under my / a Windows 7 PE 64bit environment?

Which advantages (if any) do you have in using a 64 bit PE as opposed to a 32 bit one?

Wonko

Couple of reasons...I currently only have legitimate access to Windows 7 64bit media. I borrowed the 32bit from a colleague for testing purposes only. I could however purchase Windows 7 32bit to solve that.

I run a small support company which supports a handful of SMB's. Most of our customers run Windows 2008 SBS which only comes in 64bit versions... as a result I suspect that drivers for the server hardware is only available for 64bit OS. In a disaster recovery situation (eg OS wont boot) I want to be able to pop the Win7PE disc in and gain access to the disks to repair the OS or gain access to the shared data. Granted, in this situation I wouldn't require TrueCrypt as we don't encrypt servers disks, but I would require the relevant SATA/SAS/SCSI drivers as well as LAN drivers whichmay only be available in 64bit versions due to being hardware targeted at SBS.

Increase the longevity of the disc. 32bit Windows is slowly fading out. Eventually there will be an occasion where I must have a 64bit PE environment. Its unlikely there will be an occasion where I must have a 32bit PE environment because a 64bit can do everything a 32bit can thanks to SYSWOW64 (the obvious caveat is running 16bit apps). If I get everything I need running in my 64bit PE disk now, I won't have to build another one for a good few years!

Increase the longevity of the disc. 32bit Windows is slowly fading out. Eventually there will be an occasion where I must have a 64bit PE environment. Its unlikely there will be an occasion where I must have a 32bit PE environment because a 64bit can do everything a 32bit can thanks to SYSWOW64 (the obvious caveat is running 16bit apps). If I get everything I need running in my 64bit PE disk now, I won't have to build another one for a good few years!

Oh, oh. Collision detected, you just posted that you CANNOT do in a 64 bit PE what you can do allright in a 32 bit PE, so SYSWOW64, at least in this particular case, is "m00t".

If you do support, you simply NEED to have BOTH a 32 bit PE AND a 64 bit one (for those "particular" cases) as most tools/utilities used in rescue/recovery are 32 bit anyway and by using them on a 64 bit OS you introduce a layer of complexity.

Expecially in an emergency, you need IMHO to be d@mn SURE that the tool you are using (natively 32 bit) works correctly, and this is not always the case on a 64 bit system, the alternative being testing and self-validate each and every tool in the 64 bit environment in EVERY possible situation, an amount of work (if done thoroughly) that it's impossible in practice.

I think that if you have a 64 bit OS license you are anyway legally entitled to use the WAIK to buld a 32 bit PE.

Collision detected, you just posted that you CANNOT do in a 64 bit PE what you can do allright in a 32 bit PE, so SYSWOW64, at least in this particular case, is "m00t".

Based on the fact it appears the issue is related to keyboards / languages I don't believe this is truly a 32 vs 64bit issue, more of a "how a 64bit PE disk is created" issue. I believe this to be the case because it does work on my Windows 7 64bit workstation.

If you do support, you simply NEED to have BOTH a 32 bit PE AND a 64 bit one (for those "particular" cases) as most tools/utilities used in rescue/recovery are 32 bit anyway and by using them on a 64 bit OS you introduce a layer of complexity.

While having x86 and x64 disk would work, I really don't want to have to download two ISOs while out on site (most customers have between four and eight MB downstream, but some in rural areas might be as slow as 1mb, which makes the download time about an 45mins). In an ideal world I'd carry them with me, but I'm the type of bloke who never puts things back when I've finished with them (ask my fiance!) and I've lost count the number of times I've gotten on site thinking I have my XP PE disk on me, only to find I don't! Annoying and embarrassing so I keep a copy on a privately accessible server.

Expecially in an emergency, you need IMHO to be d@mn SURE that the tool you are using (natively 32 bit) works correctly, and this is not always the case on a 64 bit system, the alternative being testing and self-validate each and every tool in the 64 bit environment in EVERY possible situation, an amount of work (if done thoroughly) that it's impossible in practice.

I agree with you on this, I really do need to know everything is working as it should (hence why I was testing everything I could and how I noticed I couldn't mount encrypted system drivers under 64bit PE ). That said, I've been running Win7 64 on my desktop for 18months now. Never had any problem with apps not working, except for 16bit ones.

I think that if you have a 64 bit OS license you are anyway legally entitled to use the WAIK to buld a 32 bit PE. Wonko