This is  a interesting discussion about what a coldboot or cleanboot is doing, but i doubt it is relevant with the problem Don described with his ES400 The folliowing fact can be verified on ES400 or other WM 6.5 devices or older WM versions. When Email is setup and password for mailbox is filled and stored on the device. You can perform numerous coldboots without loosing the email box password. In other words a coldboot is not clearing this password , neither is it clearing a stored GPRS password. The issue which Don was experiencing on his ES400 looks to be the same as described in SR item, and it is that intermittently the email synch is not working automatically anymore. Not according the Activesync Schedule Peak or Non- Peak times. Possibly because two threads on the ES400 are trying to sync email simultanously, because of that is not allowed on the Exchange server, it  locks the user email box for a while. I am using ES400 and Moto email synch for about 5 months now and never did a coldboot wipe the passwords. Only occasionly on the later builds we experienced this temporarly not synching of mailbox. which always can be seen in the  CTRLlog  files on the device being caused by this error. ( Deactivating Skyline due to MultipleExchange disabled ) hope this helps in this discussion

The Microsoft internal master encryption key is reset by Cold Boots. See the MSDN at MSDN Blogs > Windows Mobile Team Blog > Windows Mobile 6 Storage Card Encryption FAQ. This means that you cannot access any encrptyed storage that was encoded using the 'old' key. " What happens if the device is cold booted?
If the device is reset and internal flash is cleared, the decryption keys are lost. If the keys were preserved, it would be easy to access the storage card of a stolen device by just cold booting the stolen device and clearing its storage, then re-inserting the stolen card." I believe that this same, internal master encryption key is also used to encrypt all the other encrypted fields that are Microsoft's responsibility. This means that things like passwords that Micorsoft stores are also impossible to read after a Cold Boot. The passwords can be reset using xml provisioning and the like but that just stores the new value encrypted with the new key. This was certainly true for Wm 5.0 and I do not belivee it has changed for WM 6.0.

Richard; I think you have to take that post with a grain of salt.   Yes, that question DOES start with: " What happens if the device is cold booted?" But keep in mind that was a question from someone who may not have been communicating precisely.  Had I been answering that question, I would have begun with something like "I think you are referring to Clean Boot not Cold Boot.".  But the person that answered the question chose instead of state the conditions under which the loss would occur but not state one way or the other whether it actually happens on a Cold Boot.  Now look at the answer, which begins with: "If the device is reset and internal flash is cleared, the decryption keys are lost. " The internal flash DOES NOT get cleared on a Cold Boot, but it DOES get cleared on a Clean Boot.  I agree completely that when "internal flash is cleared", which is what happens on a Clean Boot, the lost of the decryption keys would be expected.  But doing a Clean Boot requires special action.  On a Cold Boot, which can be invoked on an ES400 using 1+9+Power, the internal flash is NOT cleared, so the decryption keys SHOULD NOT be lost. If we find that the decryption keys ARE lost on a Cold Boot, then we had better put a MAJOR warning in the ES400 manual since there is no way to do a Warm Boot and Cold Boot (which is just called a Reset in the manual) has no warning that such a serious thing (permanent loss of access to all encrypted data) could occur from such a seemingly innocuous and easy-to-perform action. Allan

I think that the MSDN sums up most accurately the differences between Clean, Cold and Warm Boots. http://msdn.microsoft.com/en-us/library/ee490762.aspx
"Clean, Cold, and Warm Booting

1/6/2010

There are several types of boot processes: clean, cold, and warm. They differ in the following ways:

Clean booting clears all memory, including persistent storage.
Cold booting clears both program memory and storage memory, the object store.
Warm booting clears program memory, and keeps storage memory.

The following table presents the results for the different types.

Type of Boot
Device Uses the Object Store?
Program Memory
Object Store
Persistent Storage
User Data

Clean

Yes

Cleared

Cleared

Cleared, except removable storage.

Lost

 

No

Cleared

NA

Cleared, except removable storage.

Lost

Cold

Yes

Cleared

Cleared

Retained

Lost

 

No

Cleared

NA

Retained

Lost

Warm

Yes

Cleared

Retained

Retained

Retained

 

No

Cleared

NA

Retained

Lost

Program memory is typically volatile RAM, or RAM that requires power to store data. Turning the device off erases program memory.
Storage memory is nonvolatile RAM (NVRAM), or RAM that does not require power to store data. Turning off the power does not affect storage memory.
Persistent storage can be any type of nonvolatile storage, either RAM, ROM, or a hard drive. Turning off the power does not affect the persistent storage.

... ..."

It may well be that the ES400/MC65 has implemented this differently to the Micorsoft standard or that we do not use the Object Store to hold these things. As I do not have my ES400 to hand I am unable to verify directly.

Allan,          I am not certain if you mistakenly addressed this to RLH.  Nevertheless, I posted the concern.  I attempted several cold boots to the unit to try to recover the email sync via the connections established.  To no avail, the process always resulted in "cannot connect with the current settings".  This followed a condition where the battery was completely drained. After exhausting all attempts at recovery, I eventually performed a "Master Reset" (clean boot) on the device, and started fresh.  I re-installed all apps setup the connection as before and all is well. I will attempt to re-create this condition on another device. Don

Don; My post WAS to RLH since he stated that COLD BOOT caused something nasty to happen and I was trying to clarify if that was really true or if it really only happens on CLEAN BOOT.  I have been concerned for a while that unlike ALL previous devices it is not possible for a device user to manually WARM BOOT the ES400.  Since no means to WARM BOOT is provided, only a means to COLD BOOT, customers who need to reboot are likely to COLD BOOT.  This means that anything that happens on a COLD BOOT needs to be well understood since it may be happening A LOT in the field. Allan

the issue as Don described can be tracked in SR 23939 Don sent me his Activesync device logs and they show the same issue. Multiple Email box access not allowed on the Exchange server. ( Deactivating Skyline due to MultipleExchange disabled ) so far to me it looks that there are maybe two threads trying to access the same Exchange account on ES400,  this is not allowed on the Exchange server and it will not synch anymore. some time this happens in Outlook, sometimes this happens in ActiveSync.  most of the time a coldboot recovers. RLH tried to point to a coldboot erasing the mailbox password but that is surviving a coldboot. you will be only asked to fill in password if your CoreID password is changed on the Domain server. The multiple exchange error seems to be unique for ES400 , with MC75 never seen this.

Googling shows that this registry key may hold the clue. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Inbox\Svc It is reported that deleting entries here removes the cached account items. Use at your own risk!

Richard; Please tell me you DIDN'T REALLY mean that COLD BOOT will "reset the Microsoft internal encryption key".  Given that this device doesn't have a way to do a WARM BOOT, it would be a disaster if the ONLY reboot you can do causes such major havoc.  Please tell me you meant a CLEAN BOOT does that not a COLD BOOT.  I have never heard of anything that serious resulting from a COLD BOOT on any Windows Mobile device since WM5.  I can fully understand that a CLEAN BOOT would have major ramifications.I have COLD BOOTed my device numerous times and never seen the kind of result you are describing. Allan

If the work around is to use ActiveSync to kick it off then I still suspect the password is somehow wrong (ActveSync tends to operate in a somehat privileged fashion under the covers). A check of the logs at the server might help with debugging.

Don, I saw an issue one time that may or may not be related. A customer found that if he connected a unit to Activesync via USB and a sync happened through that connection, they could no longer connect wirelessly.  I found that some of the connection manager registry entries would change as soon as that sync took place through that Activesync USB passthrough connection, and they would not revert after the USB connection was broken. Is it possible that this unit was connected to the network and did an email sync through USB at some point?

Thanks Dan..as Tony suggested, I performed a sync via an ActiveSync partnership and the device can now assert the cellular or WiFi connection; however, I am now getting an "Error Synchronizing" via the wireless connection.  It will only sync via the wired ActiveSync connection. Tony indicates that there is a known issue and an SR is currently opened.  I seem to be "digging a bigger hole" for myself...may have to clean this baby and start again!!! On a side note, my other email account is still attempting the connection and failing.  Re-creating this account did not help as apparently it rebuild the account with the cached parameters.  Deleting the account did not clear the parameters!!!  CLEAN BOOT may be the only option...too frustrated to continue...not about to chase registry entries!! I hope we get some of these issues out of the way before reaching customers hands!!! Don

It is probable that the email password (or the GPRS password) was encrypted using an 'old' encryption key (i.e. a Cold Boot has occurred). Cold Boot's reset the Microsoft internal encryption key (same happens with encrypted storage - it is not accessable after a Cold Boot). Try deleteing the whole email account (after checking the GPRS password) and starting again (I am unsure as the sync requirements after this step).

Hi Don, I have seen this as well and when I go back to Activesync and click sync it will start working again and update regularly. We have an SR open for this issue. Let me know if this resolves it for you as well? Tony

Richard, thanks for the reply...already down that path, re-created accounts..re-created connections..to no avail.  I am able to browse using either the cellular default Bell ISP or a WiFi connection...email still fails to sync...really odd!!! Don