The January '08 refresh for the Outlook 2007 Auxiliary Reference is now live. In addition to a general scrub over most of the topics, there are some interesting new topics added, such as:
Timezone/rebasing docs: http://msdn2.microsoft.com/en-us/library/bb820976.aspx and http://msdn2.microsoft.com/en-us/library/cc160684.aspx
Protecting open PST files when you crash: http://msdn2.microsoft.com/en-us/library/cc160695.aspx
Rules processing in the wrapped PST: http://msdn2.microsoft.com/en-us/library/bb820947.aspx
Additionally, my update to the wrapped PST has been incorporated.
Would MAPICrashRecovery also also immediately release PST file handles so that I can open them?
Well - I wouldn't try to abuse the API for that purpose, but if MAPICRASH_SYSTEM_SHUTDOWN hasn't been passed, the PST can still be accessed (using MAPICRASH_CONTINUE), so clearly we wouldn't want to release the lock then. But if MAPICRASH_SYSTEM_SHUTDOWN were passed I suppose the lock might be released.
However - that said - a nuance that didn't make it into the docs is that MAPICRASH_SYSTEM_SHUTDOWN is supposed to prevent ALL processes from accessing the store. So you're definitely on your own if you try to use MAPICRASH_SYSTEM_SHUTDOWN at any time other than system shutdown.
Just so that I understand how this works: calling MAPICrashRecovery affects all active MAPI sessions in the current process, right? Or is it all processes for the current Windows user?
When is the first time I will be able to open the PST files again? Is it
1. after Windows restart?
2. Process restart?
3. unloading/reloading olmapi32.dll?
4. Opening a new MAPI session in the same process?
If MAPICRASH_SYSTEM_SHUTDOWN is used it would affect all processes (though perhaps only all processes in the current current Windows session), but it should only be used when shutting down the system. So you wouldn't want to touch the PST until restart.
If only MAPICRASH_RECOVER is used, then your app can't touch the PST until MAPICRASH_CONTINUE is passed. I expect other apps which have a shared session accessing the PST would still be able to work with the PST. The UnhandledExceptionFilter from the example illustrates the expected usage.
For the UnhandledExceptionFilter() sample, it works in Outlook 2003, but does not work in Outlook 2007.
The problem is the filter installed by SetUnhandledExceptionFilter() is not invoked when an unhandled exception happened in Outlook 2007. Does Outlook 2007 enforce this??
Is this expected behavior for Outlook 2007? If so, WHY? And how can we use the MAPICrashRecovery() in the way suggested in the sample?
Or, it this a bug in Outlook 2007?
The version of Outlook doesn't matter here. This should be the unhandled exception filter for *your* process that you're registering. Essentially, you're trying to keep a crash in *your* code from trashing a PST. I don't think you should be setting an unhandled exception filter as an add-in to Outlook.
Thank you Steve. It's clearer now. So the MAPICrashRecovery() is not intended to be used by third party store provider which wraps PST as its backend.
I was think that if a store provider backed by PST crashes Outlook, this is a way to ensure that the PST is in a consistent state.
In the case of a wrapped PST, Outlook's own unhandled exception filter will be calling MAPICrashRecovery.
Does not seem that updated IConverter docs made it to the refresh. At least, http://msdn2.microsoft.com/en-us/library/aa192944(office.11).aspx still does not have a reference to SetAddressBook
You're looking in the 2003 integration API. We updated the 2007 Auxilliary Reference. Here's what you're looking for:
As for wrapped PST.
Can we use this call it from inside unloading provider to protect PST trashing?
Just to be sure if some third party code have not released MAPI object references.
As for UnhandledExceptionFilter it seem Outlook 2007 hooks SetUnhadledExceptionFilter and prohibits setting third party filters.
You should only be using this in your own processes where you load MAPI. Outlook will handle this for it's own process.