Sending without blocking Outlook so that it is unresponsive means that we have to cancel the original send, do encrypt / sign and then invoke the send once the crypto is done.
It has been reported by a user that this crashes reliably for him. While this is very stable for me and for other testers of the beta.
Currently there is an option to disable async crypto because of this. But we need to figure this crash out before we can finally release this change as default.
| rGTO Gpg4win-Tools | |||
| rGTOa74cb061a90d Add (debug) option to disable sync encryption | |||
| rO GpgOL | |||
| rO9e991ffe8466 Ignore disable async crypto option | |||
| rOc1085f44e177 Make async encryption optional | |||
| rO7eed3c4c5e9f Fix strange crash in recipient lookup | |||
| rO39176388f3a1 Disable async crypto for now | |||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | • aheinecke | T3838 GpgOL: 3.1.3-beta20 crash when sending encrypted mail (thorugh async sending) | ||
| Resolved | • aheinecke | T4029 Gpg4win 3.1.3 |
It's currently enabled again with 27e7dfb1280f314286348a661e057eef5c8ab440 I had another intensive look at the logs from the user where it is crashing but I still don't see a problem.
The crash appears in the send event when the unload is done and the mail is released. I can't reproduce it with OL 2010 or 2013. The flow is similar, the mail is released in the send event and our mail object / event handler destroyed. But this does not crash for me.
Maybe need to figure out what is different for the user where it reliably crashes.
I made it optional for now with default on. So that if it crashes it can be disabled. We need to see if the crash is a general problem or a special problem of that one tester.
In the current gpg4win-3.1.3 beta 20 this is enabled again. It can be disabled in the options with "Disable non-blocking encrypt / sign"
As additional information it will be interesting to see if more users are affected by this.
For a final release we should not have that kind of very technical option / cause crashes. So I give this high priority as we need a solution for a final release.
Got a new OL 2013 test setup where this was finally reproducible for me.
I Learned through experimentation that the reference on "ItemLoad" is weak and that keeping it does not prevent it beeing unloaded. Application.GetReference(OlReferenceTypeStrong) which should according to documentation give a strong reference also did not work on that. But If I obtain a reference to a Mailitem through the GetInspector.CurrentItem method it is strong and will prevent early unloading.
Noticed this because OL 2013 did not crash if the sent mail was open in OutlookSpy during sending.
I need to determine a good place for the unload then I can close this issue.
This was fixed by adding a new reference mechanism with cebe6484acaa250858affa3d854ef2b25cecd59f (Where I acidentally mangled the commit message.
The original reporter confirmed the fix.