WPF in Feb CTP still breaking wherever!

The last time it threw exceptions when deserializing the BAML left and right trying to run compiled applications, if I was lucky, I managed it to run once, if it was the first WPF application to run on my system. The reason where was that it was a known bug related to non-SSE2 CPUs.

Meanwhile I upgraded my machine to an Athlon64 X2, instead of exceptions, the application is dieing now due to simple breakpoints. I still only manage to run it once, in total two times, once on the x86 runtime and once on the x64 one. There are no breakpoints in my project, so they must be inside WPF. Why is THIS now happening It's really getting frustating. It even happens on a simple empty WinFX project in Visual Studio.

Answer this question

WPF in Feb CTP still breaking wherever!

cnminor
I managed to run an empty project a couple of times with success before it broke again. What VS' debugger tells me is this:

>    ntdll.dll!0000000078ef3320()
     [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
     milcore.dll!000000005318d13a()
     milcore.dll!00000000531391f7()
     milcore.dll!00000000531390dc()
     milcore.dll!0000000053138d60()
     milcore.dll!0000000053138e03()
     milcore.dll!0000000053138f85()
     milcore.dll!0000000053138ea3()
     milcore.dll!0000000053138f50()
     milcore.dll!000000005313932d()
     kernel32.dll!0000000078d6b66a()

Pretty much not saying anything. I'll be trying the stuff in the thread linked by Ruurd this evening or tomorrow and posting the stuff with symbols, and trying to get a dump.

--edit: Actually, having downloaded imagecfg.exe and applied the uniprocessor switch on my test applications, it seems to be exactly the same multiprocessor issue as Ruurd witnessed. I was just confused at first because XAMLPad.exe still crashed after that treatment, however paying attention a bit more I noticed it was missing an assembly after running imagecfg.exe on it.

So I guess I have to find a way to automatically tag the executable as uniprocessor right after compilation, at least until there's a CTP with the fix.

Thanks for the help, guys.
laweber3

Can you get a stack trace or exception message for the WPF apps that failed to launch

What is the CPU model and software specs on the machine
american_werewolf
Well, it's easy to reproduce on this end. Goes like this:

- Fresh booted x64 machine with Win2003 x64.
- Start up Visual Studio 2005, make an empty WinFX project, compile it.
- Now run it within VS, the first time it works fine. Every follow up it quits immediately without an error. Like there's no code to run.
- Now run it on the command line, again, the first time it works fine, but only because it choses the 64bit CLR over the 32bit one used with VS.
- On the command line in the 64bit CLR, the subsequent runs show the application error box. When I run the debugger from there, it tells me that the application encountered a breakpoint. No exception, a plain debugging breakpoint.
- Telling the debugger to ignore the breakpoints makes the app work. It usually only seems to run into three breakpoints, assuming during the BAML deserialization.

Whether it's release or debug, run within VS, on the command line or via the Explorer, doesn't matter. For each CLR version (32bit + 64bit), it always only runs fine for once. Which makes no sense, either. I stopped the font cache and that mscorsvw.exe optimizer thingy before rerunning an application, no dice.

The thing that's confusing is that the debugger tells me that it's a simple breakpoint that's been called. Even more confusing is that if you start the application from within VS, you don't even get an error. It just stops executing as if you'd have an empty main function.
under_way
Managed applications work fine, debugging Winforms applications does work, too. I've already tried running WinFX applications without having run anything managed beforehand, still no dice.

At least on my P3-933 and the Feb CTP, things like XamlPad continued to work all the time while selfcompiled stuff broke when possible.

I'm hoping that the March CTP comes out very soon, to see if that strange bug mysteriously went away, because it's a pretty strange issue. Especially since this is a new machine with a fresh OS install.
Wolffighters

No problem!
Allan Stirrett

Although not the same symptoms exactly, it does look like a problem we are experiencing here: http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=234330&SiteID=1

Also with athlon dual core cpu's
Vasil B
I had the problem of applications immediately exiting or just quitting immediately when I did some WPF operation on XP x64.

My problem was completely solved by installing the AMD CPU drivers from here http://www.amd.com/us-en/assets/content_type/utilities/amdcpu64.exe
Frank Natoli
RE your first point:
Yes, Feb CTP carries the fix for the problems on non-SSE2 CPUs.

RE the app dying due to breakpoints:
Just so I can isolate the problem, can you answer the following
1. What is the value of the Configuration property in your project Is it Debug Does the problem repro when you change it to Release
2. Are you hitting this issue when you hit F5 within VS What happens when you Rebuild the project, navigate to the output path (e.g. bin\Release) and run the app by double-clicking on the deployment manifest or exe, as appropriate

Terence Lee

Tom Servo wrote:
Well, it's easy to reproduce on this end. Goes like this:

- Fresh booted x64 machine with Win2003 x64.
- Start up Visual Studio 2005, make an empty WinFX project, compile it.
- Now run it within VS, the first time it works fine. Every follow up it quits immediately without an error. Like there's no code to run.
- Now run it on the command line, again, the first time it works fine, but only because it choses the 64bit CLR over the 32bit one used with VS.
- On the command line in the 64bit CLR, the subsequent runs show the application error box. When I run the debugger from there, it tells me that the application encountered a breakpoint. No exception, a plain debugging breakpoint.
- Telling the debugger to ignore the breakpoints makes the app work. It usually only seems to run into three breakpoints, assuming during the BAML deserialization.

Whether it's release or debug, run within VS, on the command line or via the Explorer, doesn't matter. For each CLR version (32bit + 64bit), it always only runs fine for once. Which makes no sense, either. I stopped the font cache and that mscorsvw.exe optimizer thingy before rerunning an application, no dice.

The thing that's confusing is that the debugger tells me that it's a simple breakpoint that's been called. Even more confusing is that if you start the application from within VS, you don't even get an error. It just stops executing as if you'd have an empty main function.

Your setup should work - I just tried it on a similar setup without problems. Do any managed apps work on your machine For example, have you successfully created and debugged a WinForms application

WPF in Feb CTP still breaking wherever!

Answer this question