none
Internal crash in UIRibbon.dll RRS feed

  • Question

  • I am developing a Windows app that is using the UIRibbon dll. I have been trying to track this seemingly random crash for months now. I have identified the culprit; UIRibbon seems to have a timer that fires and while trying to update its status calls an == operator in the UIRibbon.dll!CControlUser::GetKnownResourceType function, which is causing an access violation.

    So far, I have not been able to reproduce this on Windows 7. It is only happening on Windows 10 machines. All 64-bit. I am pretty sure it was happening on Windows 10 32-bit as well, but I will test again shortly.

    Does anyone know what this timer does?

    Unfortunately, without the ability to do source level debugging, all I can see are symbols and x86 registers. If I could have my way, I would simply source-debug UIRibbon and solve the problem. If anyone from Microsoft is listening, my company would be willing to sign whatever NDAs would be required to make this happen.

    Here is a stack trace of the error. If I could find out which command ID is leading to the crash from InvalidateUICommandInternal, that might lead me to the culprit if it is indeed on my end. What doesn't show here is that COfficeSpaceUser::s_TimerProc sends a message that kicks this process off. This trace picks up where the timer's message is being processed. This is why this bug is so hard to consistently reproduce; I can't directly cause it to happen.

    Exception thrown at 0x7BBBF088 (UIRibbon.dll) in xxx.exe: 0xC0000005: Access violation reading location 0x12EDE44C. occurred
    UIRibbon.dll!
    operator==(struct _tagpropertykey const &,struct _tagpropertykey const &)
    UIRibbon.dll!CControlUser::GetKnownResourceType(struct _tagpropertykey
    const *,enum tagEResourceType *)
    UIRibbon.dll!CControlUser::CacheInvalidateUICommand(
    enum UI_INVALIDATIONS,struct _tagpropertykey const *)
    UIRibbon.dll!COfficeSpaceUser::InvalidateUICommandInternal(
    unsigned int,enum UI_INVALIDATIONS,struct _tagpropertykey const *,enum INVALIDATIONEXCLUSION) Unknown
    UIRibbon.dll!COfficeSpaceUser::OnUpdate(
    void)
    UIRibbon.dll!COfficeSpaceUser::FrameListenerWndProc(struct HWND__ *,
    unsigned int,unsigned int,long,long *)
    UIRibbon.dll!COfficeSpaceUser::s_FrameListenerWndProc(
    void *,struct HWND__ *,unsigned int,unsigned int,long,long *)
    > UIRibbon.dll!WndBridge::RawWndProc(struct HWND__ *,
    unsigned int,unsigned int,long)



    Thursday, May 21, 2020 12:54 AM

All replies

  • I posted this earlier in Ribbon Development, but nothing in there seems to ever get answered...

    I am developing a Windows app that is using the UIRibbon dll. I have been trying to track this seemingly random crash for months now. I have identified the culprit; UIRibbon seems to have a timer that fires and while trying to update its status calls an == operator in the UIRibbon.dll!CControlUser::GetKnownResourceType function, which is causing an access violation.

    So far, I have not been able to reproduce this on Windows 7. It is only happening on Windows 10 machines. All 64-bit. I am pretty sure it was happening on Windows 10 32-bit as well, but I will test again shortly.

    Does anyone know what this timer does?

    Unfortunately, without the ability to do source level debugging, all I can see are symbols and x86 registers. If I could have my way, I would simply source-debug UIRibbon and solve the problem. If anyone from Microsoft is listening, my company would be willing to sign whatever NDAs would be required to make this happen.

    Here is a stack trace of the error. If I could find out which command ID is leading to the crash from InvalidateUICommandInternal, that might lead me to the culprit if it is indeed on my end. What doesn't show here is that COfficeSpaceUser::s_TimerProc sends a message that kicks this process off. This trace picks up where the timer's message is being processed. This is why this bug is so hard to consistently reproduce; I can't directly cause it to happen.


    Exception thrown at 0x7BBBF088 (UIRibbon.dll) in xxx.exe: 0xC0000005: Access violation reading location 0x12EDE44C. occurred
    UIRibbon.dll!operator==(struct _tagpropertykey const &,struct _tagpropertykey const &)
    UIRibbon.dll!CControlUser::GetKnownResourceType(struct _tagpropertykey const *,enum tagEResourceType *)
    UIRibbon.dll!CControlUser::CacheInvalidateUICommand(enum UI_INVALIDATIONS,struct _tagpropertykey const *)
    UIRibbon.dll!COfficeSpaceUser::InvalidateUICommandInternal(unsigned int,enum UI_INVALIDATIONS,struct _tagpropertykey const *,enum INVALIDATIONEXCLUSION) Unknown
    UIRibbon.dll!COfficeSpaceUser::OnUpdate(void)
    UIRibbon.dll!COfficeSpaceUser::FrameListenerWndProc(struct HWND__ *,unsigned int,unsigned int,long,long *)
    UIRibbon.dll!COfficeSpaceUser::s_FrameListenerWndProc(void *,struct HWND__ *,unsigned int,unsigned int,long,long *)
    > UIRibbon.dll!WndBridge::RawWndProc(struct HWND__ *,unsigned int,unsigned int,long)

    Thursday, May 21, 2020 8:11 PM
  • Hi,

    Thanks for posting here.

    Sorry for the delay. The second post is duplicated, so I have merged it to the Ribbon forum here.

    And could you please provide a reproducible sample? Since we are still not sure what the specific error is.

    Thanks,

    Drake


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, May 22, 2020 2:26 AM
    Moderator
  • Thanks for the reply, Drake. I wish it were feasible for me to post a simple reproducible sample. Let me back up a bit and explain how I have gotten here.

    I have been developing a large business management Windows Forms application for several years now. It has seen quite a lot of platform evolution over time. Three years back, I decided to spruce things up with a ribbon framework written entirely in .NET. As I retrofitted about a dozen forms with ribbons, I realized I was going to have to invest more into the bug fixing and feature implementation in this package than made sense to me. I then found RibbonLib and then ultimately the Sunburst ribbon package which are .NET interop wrappers around the UIRibbon control. Standardizing on the Windows ribbon control seemed like a great idea.

    These packages are pretty much unsupported now as the developers have moved on to bigger and better things. As I began to introduce these new ribbons into the app, this "random" crash began to appear. I would be working along and out of the blue, the app would crash due to an access violation. After enabling native debugging, I was able to create the stack trace seen in the first post. There are multiple paths in the app to make it crash, but they all look exactly like the trace in the post. Most of the time it is really just random when it decides to crash. (spoiler: the crash mechanism is always the same as I'll explain next).

    I have invested many hours going over the RibbonLib and Sunburst code, paying particular attention to the interop code. As Sunburst is a derivative work from RibbonLib, the code is nearly identical (mostly namespace changes). The crash itself is nonlinear; there is never a direct line from my code through interop to UIRibbon to the crash site. The crash is always started by a timer internal to UIRibbon which attempts to do some UI housekeeping and crashes while comparing two struct _tagpropertykey references. This makes it nearly impossible to determine what the housekeeping is doing just prior to the crash. If I could examine the internal data in the debugger (would require the source code), I would probably be able to see if there was a particular command ID coming from my code that was causing the crash. I could then possibly formulate a workaround.

    The author of the Sunburst package has added me as a contributor to the project. I signed on initially to add localization support to the ribbon, but any further investment in the codebase is predicated upon solving the "random crash" problem. Understandably, Mr. Kent doesn't want to touch it.

    I have not seen the crash happen at all under Windows 7, just Windows 10. As I understand it, there were some functional changes made to UIRIbbon.dll for Windows 8. Maybe that could be a clue.

    I would be willing to share the base module of the app that crashes on its own, but it requires almost a dozen NuGet packages and consists of 8 or so projects. It's about 40,000 lines of code. The whole thing is 26 projects and 250,000 lines.

    Another way forward I can see is to selectively delete controls in the ribbon markup until the crashing seems to go away. Fortunately, I have a scenario that will crash within a dozen iterations with only the main app form. Maybe then I can start a new project and bring in small code pieces from the app that will cause the new project to crash also. Then I could post the new project here. As you can imagine, this will require many tens of hours of work to accomplish, if it's even possible at all. Even then, there's no guarantee anyone in this forum will be able to diagnose the problem any further than I already have unless they have the ability to source-level debug UIRibbon.dll.

    The last resort is for me is to abandon UIRibbon completely and purchase ComponentOne to complete the project. At some point I have to stop throwing good money after bad ;-)

    Here's the best idea, in my opinion... If I could get the UIRibbon source code (under NDA if need be), I could identify the problem all on my own. It hasn't been that long since I specialized in C++. When it is identified, I will post a paper on it here. The only problem with this idea is that I don't have access to the right people at Microsoft to even begin the discussion of how to get the source code into my hands.

    What further questions do you have? I will do my best to answer them. How would you like (for me) to proceed?

    Thank you!

    Tuesday, May 26, 2020 5:43 PM