Access violation when copying Outlook 2016 messages to UR via extension

[cnewtonne]

Hi all ...
Any idea what can be done to resolve this issue, please. It reproducible every time I use the Outlook plugin to 'copy' a message to UR. I tried several messages from several folders, same result.

Ultra Recall Professional 5.2
Copyright © 2004-2016 Kinook Software, Inc.
Registered to: ############ (1-user license)
Windows version: Windows 10 Pro
Install path: C:\Program Files (x86)\UltraRecall
hrs32.dll version 5.0.1.3
hts11.dll version 11,0,2,3
mimepp.dll version 3.0.4
MSPTLS.DLL version 16.0.6925.1014
PolarSpellChecker.dll version 4.0.5.4
RICHED20.DLL version 16.0.6925.1014
SftPrintPreview_IX86_U_20.dll version 2.04
ter16.dll version 16.0.5.0
UltraRecall.exe version 5.2.0.7
unins000.exe version 51.52.0.0
Database filename: C:\Users\...\XXXX.urd
Database version: 4.0.1 [FTS]

[cnewtonne]

Error occurs when using 'copy' or 'link'.

[kinook]

Not really, that works in my tests.

[cnewtonne]

Do you mind posting help / about. I'm suspecting rich20.dll thing again. Also, this was working fine till last week. I did an office update over the weekend and it has not worked since then.

[kinook]

Ultra Recall Professional 5.2
Copyright © 2004-2016 Kinook Software, Inc.
Registered to:
Windows version: Windows 10 Pro
Install path: C:\Program Files (x86)\UltraRecall
hrs32.dll version 5.0.1.3
hts11.dll version 11,0,2,3
mimepp.dll version 3.0.4
PolarSpellChecker.dll version 4.0.5.4
SftPrintPreview_IX86_U_20.dll version 2.04
ter16.dll version 16.0.5.0
UltraRecall.exe version 5.2.0.7
unins000.exe version 51.52.0.0
C:\Windows\SYSTEM32\MsftEdit.dll version 10.0.10586.0 (th2_release.151029-1700)
C:\Windows\SYSTEM32\RichEd20.dll version 5.31.23.1231
Database filename:
Database version: 4.0.1 [FTS]

[cnewtonne]

Thank you.
I tried using 5 different releases of riched20.dll/msptls including %windir% default ones. All of them produce same problem.

I appreciate that you took the time to test it in your lab. It is not conclusive, however, as to why it is crashing on mine.

What can be done to advance our troubleshooting for this failure. I do not see mso20win32client.dll in the folder location described in the message. It exists in C:\Program Files (x86)\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\OFFICE16

There are 2 files of same version, yet different sizes. Not sure why.

How do these files compare to your setup. Again, I'm using Windows 10 and Office 16 with latest updates for both.

Can UR be debugged? Can we trace its calls?

Thanks

[kinook]

Office uses some sort of weird virtual file system redirection for loading DLLs. One of the DLLs is 64-bit and the other is 32-bit. The versions/sizes of that file on my test system is:

Directory of C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16

05/26/2016 02:28 PM 3,469,568 Mso20win32client.dll

Version: 16.0.6925.1014


Directory of C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16

05/26/2016 02:23 PM 2,323,712 Mso20win32client.dll

Version: 16.0.6925.1014


I would guess that a recent Office update is the reason for the different behavior on your machine (I don't have automatic updates enabled on the test system).

The access violation is occurring in the Office DLL, not UR code that we could debug.

[cnewtonne]

Does not look like humanity at large has yet known of my issue. Googling 'Mso20win32client.dll 16.0.6925.1014' yields 0 hits

All I can find is this file got updated April 5, 2016, update for Office 2016 (KB3114535) Mso20win32client.dll 16.0.4366.1000

This is a major step in my daily workflow. Sad to see it broken like this. Change is hard specially at my age.

I'll keep an eye for future UR & Office updates. Hoping one day it will fix itself.

[cnewtonne]

Kinook ...
The error message says 'error processing command line'. What command line it is referring to?

What command line/API is it calling?

[kinook]

The UR Outlook add-in calls UR with a command-line flag of /linkoutlook or /copyoutlook.
http://www.kinook.com/UltraRecall/Ma...linesyntax.htm

UR then uses the MAPI & Outlook object model APIs to locate and process the selected Outlook item(s).

[cnewtonne]

So may be the Outlook 2016 API's or the object model got changed. UR may be using older version of the calls.

Not sure if Office 2016 guarantees backward comparability. Does it?

Thanks

[kinook]

I'm sure Microsoft wouldn't intentionally break an API in this way.

[cnewtonne]

So, what can we do now.

As an end-user, I'm left now with a broken functionality that is essential and advertised as a major feature of the product. UR ability to sync with Outlook.

I do not believe it is reasonable to ask the user to downgrade Windows or Office. Kinook built the product to integrate with Outlook. I believe they need to do whatever is necessary to make sure the product works.

We can not blame Microsoft for this. They lead on this technology of Office and when third party developers integrate with it, they have to continue to maintain their apps accordingly.

I will do whatever it takes on my part to help.

[kinook]

Yes, we can blame Microsoft and can't be expected to debug or work around every one of their bugs. After installing all Windows & Office updates on our test system,

C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16\Mso20win32client.dll

version is now 16.0.6925.1016, and I could reproduce the behavior you reported with Outlook sync. Restoring the previous version of that DLL (16.0.6925.1014) resolved the issue. Here is the .1014 version of the DLL in case you don't have it:

http://www.kinook.com/Download/Misc/...in32client.dll

[cnewtonne]

I'm missing something. I'm still getting same error.

I copied the file from the link you provided to ...
- C:\Program Files (x86)\Microsoft Office\root\vfs\ProgramFilesCommonX86\Microsoft Shared\OFFICE16
- C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE16\ (as reported by error message)

I verified 'details' tab for both. It pointed to *.1014

Did an UR/Office as well as system reboots. No luch.