May, 2012

  • Akash Blogging......

    After installing KB 2553248, Outlook 2010 starts to crash when we open Meetings in the Calendar

    • 0 Comments

    Here's a scenario we recently had reported: A customer running Outlook 2010 installs KB 2553248, and now Outlook crashes when they try to open meetings that were created using Exchange Web Services (EWS). In fact there are a few other scenarios where Outlook crashes:

    1) Create a Meeting request using EWS and send it to yourself. When you receive it in Outlook 2010 as a No Response Required meeting request, just selecting the meeting request crashes Outlook.
    2) Opening the meeting in the Organizer's Calendar crashes Outlook.
    3) If the attendee sends an acceptance, selecting the acceptance in the Explorer crashes Outlook.
    4) Dismissing reminders crashes Outlook.

    The issue is happening because there was a change made in Outlook which caused it to crash when it encounters a Time Zone property on a meeting which does not have a name. If we use MFCMAPI to dump out the properties of a Meeting we can see the problem is with PidLidAppointmentTimeZoneDefinitionStartDisplay. Notice that szKeyName is null.

    <property tag = "0x80380102" type = "PT_BINARY">
    <NamedPropGUID>{00062002-0000-0000-C000-000000000046} = PSETID_Appointment</NamedPropGUID>
    <NamedPropName>id: 0x825E=33374 = PidLidAppointmentTimeZoneDefinitionStartDisplay, dispidApptTZDefStartDisplay</NamedPropName>
    <Value>cb: 76 lpb: 000000000000000000000000000000000000000000000000000000000000000000000000000000</Value>
    <AltValue><![CDATA[............>...A...............ð...........................................]]>
    </AltValue>
    <SmartView><![CDATA[Time Zone Definition:
    bMajorVersion = 0x02 (2)
    bMinorVersion = 0x01 (1)
    cbHeader = 0x0006 (6)
    wReserved = 0x0002 (2)
    cchKeyName = 0x0000 (0)
    szKeyName = (null)
    cRules = 0x0001 (1)

    TZRule[0x0].bMajorVersion = 0x02 (2)
    TZRule[0x0].bMinorVersion = 0x01 (1)
    TZRule[0x0].wReserved = 0x003E (62)
    TZRule[0x0].wTZRuleFlags = 0x0002 = TZRULE_FLAG_EFFECTIVE_TZREG
    <Value>04:00:00.000 PM 5/5/2012</Value>
    <AltValue>Low: 0x1FE4C000 High: 0x01CD2AD8</AltValue>
    </property>

    Fortunately, the fix is in the works and if everything falls in place should be out in the June 2012 CU for Office 2010.

    If you're running into this issue you have a couple options:
    1) Uninstall KB 2553248 (obviously).
    2) Fix the Exchange Web Services code so that new meetings that are created do not crash Outlook.

    What do I need to do to fix the existing code? The change is simple:

    For Exchange Web Services Proxy code, remember to specify the Time Zone Name along with the Base Offset:

    DateTime startTime = new DateTime(2012, 05, 05, 8, 00, 00, DateTimeKind.Unspecified);
    appointment.Start = startTime;
    appointment.End = startTime.AddHours(4);
    appointment.StartSpecified = appointment.EndSpecified = true;

    TimeZoneType tzUSMST = new TimeZoneType();
    tzUSMST.TimeZoneName = "Atlantic Standard Time";
    tzUSMST.BaseOffset = "PT4H";
    appointment.MeetingTimeZone = tzUSMST;

    For Exchange Web Services Managed API provide the TimeZone like below:
    appointment.StartTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Atlantic Standard Time");

  • Akash Blogging......

    Run-time error ‘-2147352567 (80020009) when trying to do SetColumns on a Items collection in Outlook

    • 0 Comments

    Problem: SetColumns is failing on non-english versions of windows with the error message below. In fact it was even failing on a English version of windows with English Office 2010 installed.

    image

    Why would this be happening? When I looked at the system where this code was failing, it looked as if the entire list of comma separated columns was be treaded a one. When I just gave any one of the columns for e.g “FullName” in the SetColumns call, the code seemed to work just fine.

    Digging deeper to find out what the problem could be, I looked at the Region and Language settings of the problem machine and found out that the Format was set to Russian (Russia). Could this be causing a problem?

    The answer is YES, when we clicked on the Additional Settings on the Format Tab in Regional and Language settings below is what we see:

    image

    The List separator was set to a semi-colon. I went back to the code and replaced the commas with semi-colon and tested and guess what? The code worked fine with out any issues. Outlook reads the value of List separator and uses it internally to split the string. In the non-working case, since we used a comma, the entire string was be treated as one column.

    The bigger question is, how can we make our code independent of the regional settings? The easiest way to get around this issue would be to read the value of List Separator from the registry and use that.

    The Separator value is stored under the following registry hive:
    [HKEY_CURRENT_USER\Control Panel\International]

    And the value you need to read is "sList". After reading the value replace the “,” in your Field list with the separator value read from the registry and then make the call to SetColumns and you should be good to go.

    Enjoy!

Page 1 of 1 (2 items)