Showstopper:Windows 10 Creator更新后的Outlook MAPI性能出现大问题(1703) [英] Showstopper: BIG problems with Outlook MAPI performance after Windows 10 Creator Update (1703)

查看:99
本文介绍了Showstopper:Windows 10 Creator更新后的Outlook MAPI性能出现大问题(1703)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,我是b $ b $
我们有Outlook加载项,在Windows 10下工作得非常完美且非常高效。
$
之后Windows 10 Creator更新所有用户都抱怨性能急剧下降。



我开始使用调试器/分析器进行研究,最后我来了几个 

占用时间最多的MAPI方法。

它是MAPIAllocateMore / MAPIAllocateBuffer / MAPIFreeBuffer。

看起来这些方法在IMessage :: CopyTo功能中被主动使用了 

读取MSG文件。

Hi guys,

We have Outlook Add-ins which worked perfectly and VERY performant under Windows 10.
After Windows 10 Creator Update ALL users complain that performance decreased dramatically.

I started researching with debuggers / profilers and and at the last I came to several 
MAPI methods which takes the most time.
It's MAPIAllocateMore / MAPIAllocateBuffer / MAPIFreeBuffer.
It looks like these methods are used actively in IMessage::CopyTo functionality when 
MSG-file is read.

推荐答案

在您的TestMAPIAllocateBuffer中,您致电MAPIInitialize但不调用MAPIUninitialize。这是泄漏,在MAPI中,泄漏表现为关机时挂起/延迟。如果您将MAPIUninitialize添加到函数以正确释放MAPI会发生什么? 

In your TestMAPIAllocateBuffer, you call MAPIInitialize but don't call MAPIUninitialize. That's a leak and in MAPI, leaks manifest as hangs/delays on shutdown. What happens if you add MAPIUninitialize to the function to properly free up MAPI? 


这篇关于Showstopper:Windows 10 Creator更新后的Outlook MAPI性能出现大问题(1703)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆