A customer was using a product called FileSite for document management. This system heavily integrates into the entire Office suite.
One user was having issues accessing some folders under the FileSite folder in Outlook. When attempting to access these views an error message was displayed:
“Outlook Cannot Display This View”
- This issue followed the user across multiple machines, despite lack of roaming profiles
- Other users logging onto same machine were not affected
- The user also advised that intermittently it would start working, then stop again.
Second level support had tried re-creating users local Windows profile and reinstalling the application to no avail.
In this case we took a log with API Monitor (http://www.rohitab.com/apimonitor)
The nice thing about API monitor is when you monitor Visual C++ Runtime Library –> String Manipulation (CRT) or Windows Application UI Development you can easily search log for the error message displayed by program, and look backwards in log for API failures.
However in this case no obvious cause was determined.
So I did an API monitor trace of a working user repeating the same steps.
I noticed in the “broken user” we kept seeing an event like this all over the place:
When I filtered just on wcsncpy_s events we could see it came consistently before error message:
Searching the “working log” this text never occurred when browsing FileSite view:
I suspected thread may relate to conversations, as this displays conversation “threads”
However both users had “Show as conversations” ticked
Despite this I tested disabling Conversation View on broken user’s machine – When disabling it, I selected all mailboxes
And *boom* our add-in was happily working, FileSite add-in happily displaying its content in all its glory.
In this case most users had only enabled conversation for the Inbox only. When enabling Conversation View they had selected This Folder
However our broken user had selected All mailboxes …