Constant Crashes

Hi Jacob,

I'm sorry you're having trouble.  We're not aware of any major issues at the moment.

Are you able to narrow down scenarios that trigger it to happen?  Do you have a lot of files open at the same time?

Which device kind are you using, and which country are you in?  We can see if we can find anything in the exception logs that might be related to your scenario. 

Also are you on the latest version?

It seems to happen when I save a document, at least in most cases. It just locks up for 45 seconds or so and then crashes.

It seems to happen kind of randomly. For example, I could save a document once and be fine, again and be fine, but for some reason the third time it'd freeze. It's not actually every 3 saves, I'm just saying that it's not a result of saving any particular files.

Sometimes I have 20 or so files open, but some times I only have one or two.

I'm using a Windows 8 Pro 64-bit laptop, and I'm in the US.

Yes, I'm on the latest version.

Hi Jacob,

That's really weird, and you don't see any sort of error message or anything before it crashes?

We have a try...catch around the entire Save method logic too.  Any exceptions that occur should be getting caught and handled so we can display an error message to you instead of having an app crash.  Thus I'm not sure how the crash is even occurring.

Can you look in your computer's Event Viewer to see if you can find more information about the crash?

Just happened when I was closing about 5 files very quickly.

Here's what I see in event viewer:

"General:"

Faulting application name: CodeWriter.exe, version: 1.7.8.0, time stamp: 0x518ba7b2
Faulting module name: KERNELBASE.dll, version: 6.2.9200.16451, time stamp: 0x50988950
Exception code: 0xe0434352
Fault offset: 0x00014b32
Faulting process id: 0x1e90
Faulting application start time: 0x01ce57dd292aa561
Faulting application path: C:\Program Files\WindowsApps\ActiproSoftwareLLC.562882FEEB491_1.7.8.8_neutral__24pqs290vpjk0\CodeWriter.exe
Faulting module path: C:\Windows\SYSTEM32\KERNELBASE.dll
Report Id: cf94e23e-c3e7-11e2-bf8c-60eb6921af0c
Faulting package full name: ActiproSoftwareLLC.562882FEEB491_1.7.8.8_neutral__24pqs290vpjk0
Faulting package-relative application ID: App

"Details:"

CodeWriter.exe

1.7.8.0

518ba7b2

KERNELBASE.dll

6.2.9200.16451

50988950

e0434352

00014b32

1e90

01ce57dd292aa561

C:\Program Files\WindowsApps\ActiproSoftwareLLC.562882FEEB491_1.7.8.8_neutral__24pqs290vpjk0\CodeWriter.exe

C:\Windows\SYSTEM32\KERNELBASE.dll

cf94e23e-c3e7-11e2-bf8c-60eb6921af0c

ActiproSoftwareLLC.562882FEEB491_1.7.8.8_neutral__24pqs290vpjk0

App

If I might ask (and you can email this to us if you would prefer not to post it here), what is your computer manufacturer, model, and name?  Some of that info gets passed along to our exception reporting service so I'm curious if i can match it up with an entry that is there.

The event log details unfortunately aren't very helpful since there's no .NET stack trace or anything.  If the exception is happening in Microsoft's low-level kernelbase.dll, then perhaps some uncatchable exception is happening here?

Do you happen to have Visual Studio 2012?  I wonder if you could attach a debugger to the app whenever you use it and set VS to break when exceptions are thrown.  Then see if you can get any more stack trace info that way.

I'd also be curious if you could try saving to some other normal hard drive for a while to see if the problem still happens.  Then that can at least narrow down if the problem is occurring between however WinRT is communicating with that remote server.

It's an Acer Aspire Timeline X 4820TG I think, and it's name in Windows is "Rev-i5"

I do have Visual Studio 2012, but not installed on this particular machine. Over the weekend I'll install it on this cmputer and give that a shot.

I've been working off the built in hard drive this morning and it does still happen.

Hi Jacob,

I looked through our crash logs and don't see anything that looks like your machine.  Please let us know what you find with the VS debugger.

A couple more questions too...

1) Did it only start happening in the latest version?

2) Which file type(s) does it happen in?

3) When it happens are you doing anything such as saving a file AND flipping to another app at the same time?

1. It started happening with not the previous version, but the version before that, I think.

2. I've seen it in .htm, .css, and .js file types, but I can't gaurantee that it's isolated to those. I just use those way more often than any other file type.

3. Often when I finish typing a line of code, I'll instincitvely hit ctrl+s immidatialy. Could it be realated to the small gap between me stopping typing and the file saving? Also, yes, I do often hit ctrl+s, and then alt-tab to a browser to test the code I just saved immidiately. Just now, I hit save and the app froze. I let it sit there, and it recovered after 20 seconds or so. I have seen it crash if I just sit there on the screen, but it does seem to help a bit.

I also notice that sometimes it just takes a long time to save a file. For example, I'll hit ctrl+s and 30 seconds later, after making another edit, try to save again. I get an error saying that it can't save for some reason, and then I notice that it still has a red "unsaved" icon in the tab. I let it sit for another 30 seconds or so and then it saves just fine. Could this be a related issue?

I'm not sure, I've never seen it take a long time like that to save.  Unless there is some low-level latency over the network causing this, I'm not sure what it could possibly be.  Our file saving code is pretty basic and straightforward.  I could possibly see this happening when you save to a server since it would deal with networking, but saving anything locally to your own machine's hard drive should be zippy.

We really need some form of stack trace though for the crash, so I'll be interested in what you find with VS.

Yea, forgot it was a three day weekend for me, so I won't be able to really test until tomorrow. I'll be sure to let you know, though.

So, all this week and last, I've tried debugging the app with Visual Studio. It seems like debugging it causes it not to crash. I'll be sitting here with visual studio closed, working in the app, and it crashes 15 times, then I start the debugging the app, and all of a sudden it's fine. Like I said, I've been trying this for almost 2 weeks, and have yet to get anything out of debugging it. It's very strange.

That's really odd, and unfortunately since we didn't see anything in the exception logs, I'm not sure what it could be.  We've updated the third party analytics/logging component that we use for the next version, so perhaps their new version will provide some additional tracking for whatever is going on here.

Yea, it could be completely coincidental, but it's strange that it refuses to crash when I'm debugging. It does seem to "lock up" more when I'm debugging, but it doesn't actually crash. Nothing shows up in the debugger though. 

That sort of weirdness almost sounds like a platform instability to me.  And from working in multiple Microsoft platforms (WinForms, WPF, Silverlight, and WinRT), I can say that WinRT is the least "stable" one... at the current time at least.  I'm sure they are improving it though as most of their DevDiv is focusing on it now.

I think I figured out what this is. I'm 99% sure it has to do with updating the live tile. When I turn on live tiles for Code Writer, the Runtime Broker (which handles live tiles) starts eating all my resources. When I disable it, everything seesm to work (mostly) smoothly. 

All we do in the current version is do a quick badge count update based on how many unsaved documents are open.  This sort of thing occurs when files are opened, closed, saved, or if the app is closing.  I wonder why that would cause any sort of processing issue on your machine, since it's a very small update.  We still haven't see it happen on our machines.

And in the next version (2.0), we have enhanced this process more with a live tile that shows open files.