Short version: can you please test whether completely uninstalling your chosen anti-virus solution, if any, resolves this symptom. (I oughta have that line as my sig in this forum
Detail: as big as that dump is, the problem is not actually in there, though there's enough info for educated guessing. Outlook is hung because its attempt to load a DLL is not being honoured by the kernel, for reasons which are not visible in the Outlook process address space (the dump). Here's the top of the relevant thread stack: 0:000:x86> kbna # ChildEBP RetAddr Args to Child 00 003d38ac 7619dc73 003d3924 000f0005 00000000 ntdll_77c50000!NtCreateSection+0x12 01 003d3908 761a197d 00004298 00000000 00000000 KERNELBASE!CreateFileMappingW+0xe5
02 003d3ad8 761a1aed 003d3b24 003d3b1c 00000002 KERNELBASE!BasepLoadLibraryAsDataFileInternal+0x475
03 003d3af8 761a1cc6 003d3b24 003d3b1c 00000002 KERNELBASE!BasepLoadLibraryAsDataFile+0x19
04 003d3b30 761993c3 003d3b5c 00000000 00000001 KERNELBASE!LoadLibraryExW+0x114
05 003d3d68 76199539 003d3dac 003d3eb4 00000001 KERNELBASE!ConvertTimeZoneMuiString+0xe4
06 003d3d8c 76199681 003d3da8 003d3eb4 003d3f08 KERNELBASE!ConvertTimeZoneMuiStrings+0x143
07 003d3e58 7619973f 003d3eb0 00000001 003d400c KERNELBASE!GetTimeZoneInformationRaw+0x8c
08 003d3e68 76199c8d 003d3eb0 003d403c 003d4120 KERNELBASE!GetTimeZoneInformation+0xf
09 003d400c 74bf669c 003d4040 003d402c 003d4110 KERNELBASE!SystemTimeToTzSpecificLocalTime+0x57
For some perfectly mundane reason, it needed to convert timezone info (it's a scheduling app after all!), and to do that it needs to "load" the DLL which contains the conversion code: 0:000:x86> du 003d3b5c 003d3b5c "C:\Windows\system32\tzres.dll"
"Time Zone... Resource"? Bob knows what the "res" stands for, but the TZ portion of the name is unmistakeable.
The act of "loading" a DLL entails creating a so-called "file mapping object" whereby the contents of the DLL are "mapped" into the (Outlook) address space, so that the functions therein can be called to do the work that's required.
The kernel calls that same construct a "section object", and the very last (topmost) function call on the stack is the syscall down (up!) into kernel-mode for the section object to be created. Obviously, that hasn't happened for some reason, and based on your observations it's unlikely to either, irrespective of how long you wait.
The next permutation of the problem description then becomes: "why is the kernel sometimes unable to create section objects?" The answer to that question is, by definition, to be found down in kernel-mode, and the most obvious and frequent cause is interference by some type of "security" inspection driver
, hence the suggestion to try uninstalling the AV (disabling it is not a valid test).
Incidentally, this also goes a long way towards explaining the observed inability to "end task" the hung process. There's an outstanding kernel-mode call, so the act of terminating the Outlook process is not quite as simple as just shooting it in the head with the Task Manager's "end task" button. The kernel itself is now experiencing problems because of all this.