Crash if build later than 55239

Nov 17, 2010 at 2:40 PM

I'm scratching my head on this one. Any build from 55241 onwards just crashes my app. It builds fine, but there's an unhandled nullpointer exception somewhere deep inside user32.dll on startup. This occurs after my Loaded() event has run. There's no useful stack trace - everything is buried within Windows libraries

Build 55239 is perfectly fine, and this is the last release that will actually work on my system. The TestApp runs fine. I've been searching to see if there's an api change, but can't spot anything. So I'm thinking that I have something somewhere that's null, which was fine with 55239, but barfs in 55241. Any idea what that might be?



Nov 18, 2010 at 9:57 AM

Any details will be appreciated. We need a way to repro this.


Nov 18, 2010 at 12:01 PM

Here's a build. The installer is built against 55241, and when you run it, it'll crash. The extra Fluent.dll in the root of the zip is 55239. If you replace the installed file with this one, it'll work. Hope that helps.
Project is built in VS2010/.Net4.0ClientProfile



Nov 19, 2010 at 6:57 PM

I tried this myself Tim and it crashed even when I used the latest build that works fine with my app. I'm thinking you have a piece of code on a control that they changed the object structure of. Perhaps something using a text instead of Header. Without actual code to trace through I've no idea but I can say I'm not having any trouble in my app and I got a lot of good ideas from the code you shared with me originally. 

Nov 22, 2010 at 11:22 AM

Yes I agree. But the crash happens deep inside Windows, where there is no code trace available. And so I was hoping the devs (who instigated the change that causes the crash) might have an insight regarding what they changed that might have caused it to break.

Without such an insight, I'm pretty much forced to rebuild the ribbon UI from scratch, and on a project of this size, that's an undertaking I'm reluctant to do. (meaning I'm forever stuck with 55239)

Nov 22, 2010 at 4:54 PM

You can try to locate the problem by removing parts of your code. For example, derivate from System.Windows.Window instead of Fluent.RibbonWindow. Remove WebBrowser control and so on... 
I'm tried to trace your error, but it is produced by something outside Fluent code as you mentioned above.