Develop Reference

Intermittent application hang on startup in Windows Store App

I am developing a Windows Store application. Currently, I am getting intermittent hangs as described in this blog post. The issue appears to be that not enough space is given to remainder-defined column widths and TextBlocks attempting to format themselves (possibly due to the ellipsis processing). My app tends to hang indefinitely when this happens.
The question I have less related to how to solve the issue (as it seems to be described fairly well in the blog post), but instead how to find the issues. I have one fairly regularly (approximately one in five or ten start-ups) on a Hub Page, so I've been looking through there (as it's the most notable instance of issue), but it's a true Heisenbug in that it never seems to happen when debugging (or when you look for it).
So, how do I find the offending code? Is there just a pattern I need to look for (ColumnWidth="*"?). Is there a simpler way to solve this, such as changing the base style to remove one of the possibly offending properties listed in the blog post?
It seems possible that this is being caused by another issue, but this seems to be the most likely/plausible as of right now (as with the hubs I have a similar situation to what is being described there).
Also, is there a way to track when this happens in the wild? MSFT provides crash dumps on hangs, but they seem to give little to no information in them at all (and on top of that they only appear 5 days after they happen, which is less than ideal).
Thanks!

This is a complicated question to answer.
First, I think you have identified a real problem with WinRT. You theorize that the layout subsystem seems busy calculating your layout, and based on some condition that occurs around 20% of the time it does not finish in any reasonable time. Reasonable guess.
The problem, then, is when such an event does not occur during debug. In my personal development experience, errors that do not occur in debug are 99.99% timing related. Something is not finishing before a second process begins. Debugging lets those first, long process finish.
This is a real computer science question, and not so much a WinRT or Windows 8 question. To that end, the best answer I can give you without any code samples (why no code samples?) is the typical approach I employ when I reach the same dilemma. I hope it helps, at least a little.
Start with your brain.
I have always joked with developers just how much debugging can be done outside the debugger - and in your mind. Mentally walking the pipeline of your app and looking for race-condition dependencies that might cause deadlocks. Believe it or not, this solves a lot of problems a debugger could never catch - because debuggers unwind timing dependencies.
Next is simplicity.
The more complex the problem the less likely you will find the culprit. In the case of a XAML application, I tend to remove or disable value converters first. Then, I look to remove data templates. If you have element bindings, those go next. If simplifying the XAML does help - that's just the beginning to figuring it out. If it doesn't, things just got easier.
Your code behind can be disabled with just a few keystrokes and found guilty or innocent. It's the most likely place for your problem, I find, and the reason we work so hard to keep it simple, clean, and minimal. After that, there's the view model. Though it's not impossible for your view model to be the one, and indeed you still have to check, it's probably not the root of your evil.
Lastly, there's the app pipeline that loads your page, loads your data, or does anything else. Step by step your only real option is to slowly remove things from your app until you don't see the problem. Removing the problem, though is not solving it. That's a case by case thing based on your app and the logic in it. Reality is, you might see the problem leave when removing XAML, while the real problem is in the view model or elsewhere.
What am I really saying? The silver bullet you are asking for really isn't there. There are several Microsoft tools and even more third party tools to look for bottlenecks, latency problems, slow code, and stuff - but in all reality, the scenario you describe is plain ole programming. I am not saying you aren't the victim of a bug. I'm saying, with the information we have, this is all I can do for you.
You'll get it.
Third thing to do is to add logging, and instrumentation to your app.
Best of luck.

Given that Jerry has answered this at a higher level I figured I would add in the lower level answers that from the way your question is phrased makes me think you are interested in. I guess first I would like to address the last item which is the dump files. There is a mechanism for getting dump files of a process 'in the wild' that Microsoft provides which is through Windows Error Reporting. If you are wanting to collect dump files from failed client processes you could sign up for Windows Error Reporting (I must admit I have never actually done it, but I did look into it and tried to get my current employer to allow me to do this, but it didn't end successfully). To sign up go to the Establish a Hardware/Desktop Account Page.
As far as what to do with dump files once you get them, you would be wanting to download the debugging tools for windows (part of the Windows SDK download) and/or the Debug Diag Tool (I must confess I am more of a debugging tools for windows user than a Debug Diag user). These will provide you with the tools to look into what is going on at a lower level. Obviously you can only go so far as you won't have access to private Microsoft symbols, but you do have access to public symbols and usually those are enough to give you a pretty good idea of the problem area.
Your primary tools will depend on how reproducible the issue is. If it is only reproducible on some client machines then you will have to rely on looking at a single dump file that you probably got a hold of from Windows Error Reporting. In this case what I would do is open it up using the appropriate version of Windbg (either x86 or x64) and look at what was going on at the time the dump was taken. Depending on how savvy you are depends on how far you can go. Probably a simple starter would be to run
.symfix
.reload
.loadby sos clr
!EEStack
This will load Microsoft public symbols, the sos extension dll for dealing with Managed code inspection, and then will dump the contents of the stack for each thread in the process. From looking at the names of the method that appear on the call stacks you might be able to get a pretty good idea of at least the area of the code where the lock is occuring.
You can go much farther than this as Windbg provides the ability to go pretty deep into deadlock analysis (for instance there is an extension available for Windbg called sosex that provides a command !dlk which can sometimes automate the detection of a deadlock for you from a single dump file. To load an extension dll into Windbg you just have to download it and then call .load fullpathtodll). If the problem is reproducible locally you might even be more successful with WPA/WPR or if you are really fortunate a simple procmon trace. These tools do have a pretty decent barrier to entry as they take some time to learn. But if you are really interested in the topic your best resources would be the Defrag Tools series on Channel9 and anything by Mario Hewardt (especially his book "Advanced .Net Debugging"). Again, getting familiar with these tools can take a bunch of time, but at the very least if you just know how to dump the contents of the stacks from a dump file you can sometimes get what you need just from that so a basic understanding of these tools can be beneficial as well.

Accessing Physical Memory via a High Level Language e.g.

I am researching the best way to perform a dump of the memory (RAM) of a Windows 7 machine via a high level programming language e.g. C#. I have done a fair amount of research into this as I will summarize below.
•It appears that Microsoft API access to memory was cut off some time back (\Device\PhysicalMemory)
•It now appears that to gain access to the memory your code must be executed in kernel mode as opposed to user mode to allow you to access the memory
•I have looked into how Windows dump’s memory (Small, Large & Kernel dumps) upon a system hang, this method is not suitable for my requirements
I wondered if anyone had a good take upon how I should go about accessing the physical memory of a machine. My knowledge of low level coding languages is scarce as I am used to programming Window Applications. Suggestions I have received so far would include writing a driver to access the memory and then calling this via a higher level programming language.
Any help that any of the community can offer would be much appreciated! Thanks in advance.

Use procdump -ma. This gives complete state of a single process. Leave debugging the OS to kernel-mode people.
From my rather short experience with kernel-mode debugging with WinDBG, I'd recommend starting with a second PC and a Firewire link. On the system under test, remove hard drive and install the OS with symbols. Make sure you have a good base image of the OS with symbols, for the time when you break it.
On my short list of WinDBG books to read is "Programming the Windows Driver Model," Oney, MSPress.
This may help.

MWMCR::evaluatefunction error out of memory

when I run my application I got this exception
a busy cat http://img21.imageshack.us/img21/5619/bugxt.jpg
I understood that the program is out of memory .. are there any other possible meaning for that exception?
given that I am calling a dll files (deployment from matlab)
thank you all

It's absolutely possible, just use Process Explorer to see your processe's WorkingSet.
For 32 bit Windows systems maximum available memory for .NET Provecesses is arround 2GB, but it can be less based on your version configuration. Here is the SO Link on subject.
Considering the fact that you use matlab, so probably make a massive or complex calculations, you, probably, create a lot of objects/values to pass to DLL functions, which can be a one possible sources of bottleneck. But this is only a guess, cause you need to measure you program to figure out real problem.
Regards.
Note: check your old questions and accept an answer you prefer among responses you got for every question, your rate is too low !

Debugging and improving the efficiency C# winform code

I have written a Winform application in C#. How can I check the performance of my code. By that I mean, how can I check which forms references are active at a given time or event, so that I can remove them if they are not required (make them available for garbage collection). Is there a way to do it using VS 2005 or any free tool. Any tutorials or guide will be useful.
[Edit] Sorry if my question is confusing. I am not looking for a professional tool, but ways to know/understand the working of my code better and code more efficiently.
Thanks

Making code efficient is always a secondary step for me. First I write the code so that it works. Next, I profile it if i am unhappy with the performance. The truth is most applications run fast enough after the first time writing them. Sometimes though, better performance is needed. Performance can be gained many different ways. It all depends on your application. I write LOB apps mainly, so I deal with alot of IO to databases, services and storage. These calls are all very expensive and need to be limited so they are my first area to optimize. I optimize by lazy-loading, eager-loading, batching calls, making less frequent calls and so on. I recently had a winforms app that created hundreds of controls dynamically and it took a long time. That's another bottleneck that I have to address. I use a profiler to measure the performance of the applications.
Use the free Equatec profiler. It will show you how long calls take and how many times a call is made. The profiler gives a nice report and visual display that can drill down the call stacks.

Red Gate Performance Profiler
...it's been said here a million times before. If you suspect performance issues, profile your application. It will tell you how long calls are taking and point out the bottlenecks in your code.

Kobra,
What you're looking for is called a Memory Profiler. There happens to be one (paid) version for .NET aptly named ".NET Memory Profiler", I've not used it extensively but it should answer the questions you're asking. There are a few others ones which will do basically the same thing, like giving you instance counts of loaded types, and help you identify when instances are not being garbage collected for one reason or another (i.e. Event Handler References, Static Properties, etc).
Hope this helps,
Dylan

Is there a way to retrieve a C# app's current memory usage?

I am automating some profiling tasks and want to log heap space and generation sizes real-time. The profiling API seems awfully complicated for what I need, and it seems to listen in on individual allocations and collections, which isn't that important to me. Profiling tools are a great help of course, but I was looking for a more flexible, programmable interface.

The term 'current memory usage' is a little loosely defined. Do you mean the working set? Whatever it means, you can use different properties such as VirtualMemorySize, WorkingSet, PrivateMemorySize, etc. from the process class to retrieve it.
long workingSet = System.Diagnostics.Process.GetCurrentProcess().WorkingSet64;

There are performance counters for a lot of this stuff and if you can't use Perfmon, you can access counters through the Diagnostics API.

Once I had to find a memory leak in a legacy code, I came accross this solution:
Start "tasklist" with appropriate parameters as a process and read the output either from stream or from file.
e.g.
tasklist /fi "IMAGENAME eq notepad++.exe" /FO CSV /NH
Output is:
"notepad++.exe","7132","Console","1","21.004 K"
Not that elegant, but works in any programming language on Windows without additional dependences (C++/Qt in my case).