none
Changing the Outlook Recipient Sendable property crashes Outlook RRS feed

  • Question

  • I have an Outlook AddIn that is used to update contact records on a database when Appointments are created in Outlook. To do this I am trapping the property change event  for the RequiredAttendees, OptionalAttendees and Resources properties of the AppointmentItem and processing through the recipients.  One of the requirements that has come up recently is to be able to automatically switch off the Sendable property of recipients under certain circumstances.  This appears simple, but every time I update this property on a recipient in the property change event handler, Outlook crashes with an Access Violation in outlook.exe.  This happens soon after the event handler has completed, but always after completion and sometimes a few seconds later.  It also appears to only happen if the recipients are being entered via the Scheduling Assistant.

    Commenting out the single line of code that assigns the new value to the Sendable property makes the problem go away, so I know it is definitely that assignment that is causing the issue.  Assigning to the property outside the property change event handler does not appear to cause an issue.

    The information given in the event log is:

    Faulting application name: outlook.exe, version: 15.0.4551.1511, time stamp: 0x529480be
    Faulting module name: outlook.exe, version: 15.0.4551.1511, time stamp: 0x529480be
    Exception code: 0xc0000005
    Fault offset: 0x006e94ca
    Faulting process ID: 0x105c
    Faulting application start time: 0x01cf271c52110b39
    Faulting application path: C:\Program Files (x86)\Microsoft Office\Office15\outlook.exe
    Faulting module path: C:\Program Files (x86)\Microsoft Office\Office15\outlook.exe
    Report ID: dd906c80-930f-11e3-bed5-d485649616c6
    Faulting package full name: 
    Faulting package-relative application ID: 

    The Outlook version information is Miscrosoft Outlook 2013 (15.0.4551.1511) MSO (15.0.451.1007) 32 bit.  The OS is Microsoft Windows 8 Pro 6.2.9200 Build 9200 64 bit.  The VSTO version (according to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VSTO Runtime Setup\v4\Version) is 10.0.40305. 

    Any ideas?

    Wednesday, February 12, 2014 9:56 AM

All replies

  • Hello Simon,

    This property applies only to a recipient of a meeting request. If the recipient is not on a meeting request, getting and setting this property should not do anything.

    > I update this property on a recipient in the property change event

    Note, the property change event should be fired anew when you change something. Is this the case? Did you try to use any other event handler or method for setting the Sendable property?

    What code do you use for reproducing the issue? Are you able to reproduce the issue with a newly created VSTO add-in project?

    BTW Do you have any other add-ins installed for Outlook?

    Wednesday, February 12, 2014 12:35 PM
  • Show the code you're using to make the change.

    Ken Slovak MVP - Outlook

    Wednesday, February 12, 2014 3:21 PM
    Moderator
  • As I stated, the error occurs when I am adding recipients in the Scheduling Assistant. The object that I am setting the property on is an AppointmentItem object that was obtained from Inspector.CurrentItem when the NewInspector event was handled.  It does not matter if I create the meeting/appointment with Create Meeting or Create Appointment, CurrentItem is always an AppointmentItem.

    When I attempt to set the property MeetingStatus is olMeeting.

    There are a whole list of other AddIns installed, but they are all ones that were installed by the standard Office installer.  Ours is the only non-standard AddIn installed.

    The code I am using to set the property is:

    Me.AppointmentItem.Recipients(RecipientIndex).sendable = False

    If this code is executed in the Save or Write event handlers, I do not get a crash, but the assignment appears to have no effect.

    Wednesday, February 12, 2014 4:07 PM
  • I would try first to get the handle to CurrentItem and its properties after NewInspector() when you have a strong object reference in the first Inspector.Activate() event.

    I'd also separate the objects and not use compound dot operators that create objects that can't be released or accessed. For example:

    Dim oAppt As Outlook.AppointmentItem = Me.AppointmentItem

    Dim colRecips As Outlook.Recipients = oAppt.Recipients

    Dim oRecip As Outlook.Recipient = colRecips.Item(RecipientIndex)

    etc.


    Ken Slovak MVP - Outlook

    Wednesday, February 12, 2014 4:15 PM
    Moderator
  • I have trapped the Inspector.Activate event and Inspector.CurrentItem is the same object as that obtained in the NewInspector event handler, i.e. 

    Me.AppointmentItem is Inspector.CurrentItem

    evaluates to True.

    I have also proved that the attempt to set the Sendable property of the recipient is not executed before the Activate event fires.

    Please do not lecture me on coding style, it is not relevant to the issue.  I have 30 years experience writing code in a large number of languages including IBM S/370 assembler, x86 assembler, M68K assembler, COBOL, PL/1, Java, C++, C, C# and VB .NET.  I have written software for Mainframes, tablets, phones, PCs and embedded microcontrollers.  I have written software to run under C/PM, z/OS, MSDOS, every version of Windows since 3.1, Solaris, AIX, Linux and other operating systems.  I define variables to hold items I use a number of times and do not define variables to hold items that I use only once.  Other people do things differently and that is their prerogative.

    Thursday, February 13, 2014 10:01 AM
  • Hi Simon,

    I don't want to argue but the first thing I'd recommend to do is to break the chain of calls into separate lines of code (later I will explain you why) due to the fact that you don't release underlying COM objects instantly:

    Me.AppointmentItem.Recipients(RecipientIndex).sendable = False

    The Recipients property of the AppointmentItem class returns an instance of the Recipients class which should be released after (i.e. the reference counter of the corresponding COM object should be decreased). Then you get an instance of the Recipient class which should be released after too.

    Use System.Runtime.InteropServices.Marshal.ReleaseComObject to release an Outlook object when you have finished using it. Then set a variable to Nothing in Visual Basic (null in C#) to release the reference to the object. You can read more about this in the Systematically Releasing Objects article in MSDN.

    Thursday, February 13, 2014 12:21 PM
  • Okay, I stand corrected.  I knew there was a reason I avoided using COM.  Of course, avoiding it means not picking up on this sort of strange behaviour!  I will amend my code accordingly.  Every day is a school day!!!

    Thursday, February 13, 2014 1:48 PM
  • Let me know your results after, whether it helps or not.
    Thursday, February 13, 2014 2:26 PM
  • I'm afraid that it makes no difference.

    The code now looks like:

            Dim vRecipients As Outlook.Recipients = Me.AppointmentItem.Recipients
            Me.dgrContacts.Rows.Clear()
            If vRecipients IsNot Nothing AndAlso
               vRecipients.Count > 1 Then
              Dim vRecipientIndex As Integer = 2
              While vRecipientIndex <= vRecipients.Count And Not mvContactResolutionRestartRequired
                Dim vRecipient As Outlook.Recipient = vRecipients(vRecipientIndex)
                Dim vEmailAddress As String = ResolveRecipientToContact(vRecipient)
                Dim vContactName As String = vRecipient.Name
                Dim vContactId As String = String.Empty
                Dim vContactFound As Boolean = mvResolvedContents.ContainsKey(vEmailAddress) AndAlso
                                               mvResolvedContents(vEmailAddress) IsNot Nothing
                If vContactFound Then
                  vContactName = mvResolvedContents(vEmailAddress).ContactName
                  vContactId = mvResolvedContents(vEmailAddress).ContactNumber.ToString
                End If
                Me.dgrContacts.Rows.Add(If(vContactFound, 1, If(String.IsNullOrEmpty(vEmailAddress), 2, 0)),
                                        "Click to re-attempt the match.",
                                        vContactName,
                                        vEmailAddress,
                                        vContactId)
                Me.dgrContacts.Rows(Me.dgrContacts.Rows.Count - 1).Cells(1).ToolTipText = "Click to re-attempt the match."
                If vRecipient.Resolved Then
                  If vRecipient.Sendable Then
                    vRecipient.Sendable = False
                  End If
                End If
                Marshal.ReleaseComObject(vRecipient)
                vRecipient = Nothing
                vRecipientIndex += 1
              End While
              Marshal.ReleaseComObject(vRecipients)
              vRecipients = Nothing
    

    One other thing that might help narrow the search is that the crash only occurs if the recipient is added using the Scheduling Assistant panel.  Adding the recipient via the 'To:' line on the Appointment panel does not cause the issue, but the added recipient is made not sendable as expected.

    Thursday, February 13, 2014 3:04 PM
  • The Inspector object you get in NewInspector() is a weak object reference, In the Activate() event it's a strong reference. The first thing to always check is whether things work with the strong reference where they won't with the weak one. The objects are the same, how "filled out" they are is different.

    As you appear to have discovered, not using compound dot operators is basic to coding .NET code. I've been programming for over 30 years also, what I do and learn with managed code is different than other coding paradigms I've used, including embedded microcontrollers and using assembly code directly in hex.


    Ken Slovak MVP - Outlook

    Thursday, February 13, 2014 3:43 PM
    Moderator
  • As I thought you suggested yesterday, I changed the code so that it just gets the Inspector from the NewInspector event and then traps the Activate event on that to set the backing variable of the AppointmentItem property.  The handler for the Activate event on the Inspector is:

      Private Sub mvInspector_Activate() Handles mvInspector.Activate
        Me.AppointmentItem = CType(Me.Inspector.CurrentItem, Outlook.AppointmentItem)
      End Sub
    
    The UserControl containing this code is constructed in the NewInspector event and the Inspector is passed in the constructor (I was passing the AppointmentItem in the constructor previously).  Am I missing something?

    Thursday, February 13, 2014 4:21 PM
  • You're not missing anything with that. It does eliminate one possible problem however, so it's a useful exercise. The code now follows best practices for that.

    Have you tested this with any other version of Outlook, or only Outlook 2013 so far? If I get a chance later this afternoon I'll try to put together some simple test VBA code and see if I see the problem in 2013 and also in 2010.


    Ken Slovak MVP - Outlook

    Thursday, February 13, 2014 4:32 PM
    Moderator
  • This functionality is Outlook 2013 specific.  We only link into email functionality in earlier versions of Outlook, sorry!
    Thursday, February 13, 2014 5:19 PM
  • Can you get the Fault bucket from the Event Viewer Application Log Event 1001 for the corresponding crash? I can have that checked to see if it's linked to one of the existing fixes in Outlook 2013 SP1.

    If not, and it proves to be a bug, then it would still be open.


    Ken Slovak MVP - Outlook

    Thursday, February 13, 2014 5:47 PM
    Moderator
  • This is the fault bucket:

    Fault bucket 73027969423, type 1
    Event Name: APPCRASH
    Response: Not available
    Cab Id: 0
    
    Problem signature:
    P1: outlook.exe
    P2: 15.0.4551.1511
    P3: 529480be
    P4: outlook.exe
    P5: 15.0.4551.1511
    P6: 529480be
    P7: c0000005
    P8: 006e94ca
    P9: 
    P10: 
    
    Attached files:
    C:\Users\simon.williams\AppData\Local\Temp\77917413.cvr
    C:\Users\simon.williams\AppData\Local\Temp\CVR52B9.tmp.cvr
    C:\Users\simon.williams\AppData\Local\Temp\WEREDC0.tmp.WERInternalMetadata.xml
    
    These files may be available here:
    C:\Users\simon.williams\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_outlook.exe_75e1ca4a7dbc65f659d2e0acfbc1d57c87edd8a7_148d062f
    
    Analysis symbol: 
    Rechecking for solution: 0
    Report ID: ea3488e3-94c1-11e3-bed7-d485649616c6
    Report Status: 0
    Hashed bucket: 6039c093f1ec64841413b5a1c0872cfe

    If you need any of the files then I send them to you.  At least one of the crash reports has been sent to Microsoft, but probably not until this week.

    Friday, February 14, 2014 8:47 AM
  • Thanks. Depending on the crash the dump files could be huge. I've uploaded some that have been a couple of GB.

    I provided the fault bucket information to the Outlook product group, I'll post back here when they give me more information.


    Ken Slovak MVP - Outlook

    Friday, February 14, 2014 3:17 PM
    Moderator
  • I'm told "the product group does have a log for this crash but it is not associated with a bug yet.  The logging shows they've had 140 crash reports and these started on January 15.  1/15 is the day after patch Tuesday so possibly being caused by the January PU, http://support.microsoft.com/kb/2850061. You could ask the customer to remove the update and check if that is the cause.  Here are instructions in case they are C2R, http://support.microsoft.com/kb/2770432.  We do not have any cases on this yet so please encourage the customer to open one."

    So, try removing that update and see if that fixes the problem. Please let us know the results here.

    If you can open a support case, please do so, there would be no charge if the problem is a bug.


    Ken Slovak MVP - Outlook

    Saturday, February 15, 2014 2:54 PM
    Moderator
  • I have uninstalled update KB2850061, but the issue still exists, so it wasn't introduced by that.  I would suggest that there should be no question as to whether this is a bug.  I should not be able to use a published API to change a property in such a way that it causes the program providing that API to crash with an Access Violation!  Even if I do something really stupid, the API should fail gracefully!!!  However, since there does seem to be question as to whether this is a bug, I cannot raise a support issue as I have no authority to enter into any agreement with any third party that may result in a cost to the company.
    Monday, February 17, 2014 2:53 PM
  • A crash is a bug, but I'm not able to make a final determination on that for a support case. That would have to be done by MS. For a bug there is no charge for a support incident. It's up to you and your company whether or not you decide to open a support incident.

    I reported your answer to the product group and will leave it up to you and them what to do next.


    Ken Slovak MVP - Outlook

    Monday, February 17, 2014 3:11 PM
    Moderator
  • Please could you give me a link to details on how to raise a support incident?  It's not something I have needed to do before.  I have gone to the MSDN site and followed the links to the support page, but after filling in the basic details I get a page that only gives me the option of having a support representative contact me at my cost.  The URL I end up at is https://support.microsoft.com/getsupport/hostpage.aspx?tenant=ClassicCommercial&locale=en-gb&supportregion=en-gb&ln=en-gb&pesid=14894&sd=msdn&oaspworkflow=start_1.0.0.0&wf=0&ccsid=635282221722650860.

    Thanks for all your help.

    Monday, February 17, 2014 4:28 PM
  • I know that you have to supply a credit card number initially, but it won't be billed if the incident is determined to be a bug in Outlook.

    How you file a support incident depends on whether or not you have an MSDN subscription and as a partner what partner benefits you have.

    For example, I have an MSDN subscription which provides 3 support incidents. If I use one of them I don't have to supply credit information, and if it's a bug I get credit for the support incident I used.

    If you have MSDN log in and see what benefits you have, same for your partner account. If neither of those applies I guess the link you ended up at is as good as any. I'm in the U.S., so I'd end up at a different place if I went through the general support link.

    If you still have problems opening a support incident post back and I'll ask my contacts in support how and where you should open the support incident.


    Ken Slovak MVP - Outlook

    Monday, February 17, 2014 5:01 PM
    Moderator