DeviceNetworkInformation.ResolveHostNameAsync breaks tombstoning - major bug


  • Hi.

    We have a WP7 app that has difficulties resuming from tombstoning. When we test that functionality in the VS 2010 debugger, the app hangs with the "Resuming..." message in both emulator and phone. No exceptions are thrown, and no interesting output messages are visible.

    A lot of trial and error later, I've narrowed the issue to our use of DeviceNetworkInformation.ResolveHostNameAsync. When we call this API with a string representing a netbios computer name, the API succeeds, but the app will never resume from tombstoning again.

    I know this sound weird.  But it's 100% reproducible in our app.  It's essentially the same issue as this one, so I don't think it's just us:

    I don't want to have to choose between name resolution and tombstoning, but it looks like that's how it's going to be.

    Thursday, April 05, 2012 12:08 AM

All replies

  • Does this happen only when the debugger is connected? If yes, can you resume the app by hitting F5 as mentioned in the stackoverflow link?

    - Mark
    Thursday, April 05, 2012 3:11 PM

  • I don't want to have to choose between name resolution and tombstoning, but it looks like that's how it's going to be.

    You are right, easy to duplicate using the simple code from the url you posted. It also locks up the emulator (512MB 7.1.1) when you stop debugging and start debugging again. All I get is my splash page and the emulator is hung up until you close and restart the emulator. Didn’t try it on my phone, don’t want to hose it, if it is an OS bug.


    As far as choosing between name resolution and tombstoning, not sure on that one.


    Not a fix to your problem, just some of my thoughts on tombstoning. You could try to tombstone your app on your test phone(s) and see if you have better luck getting it to really tombstone on the phone, maybe your decision would be easier.


    I haven’t been able to get my phone to tombstone, I posted this;



    No ideas yet on how to test.


    Based on my simple tests, it appears that 5 apps are the max, regardless of the memory they use. The sixth added terminates the first. If the OS was intelligent, I would think it would tombstone the first apps to save memory.


    As a simplified example, let’s say I have 100k of memory, and 5 apps taking 20k. They can be FASed. So I launch an app that takes 20k, no memory left. So the OS would tombstone 2 apps, this would free up 40k, minus whatever is in the PhoneApplicationService.Current.State dictionary for each app. Lets say each app has 5k in its state dictionary, so tomstoning these 2 apps frees up 30k, enough for the sixth app. And so it goes until all that is left is tombstoned app’s state dictionaries consuming all the memory.


    To get a better payback on my efforts in coding for tombstoning, I ended up adding the ability to save/ restore the PhoneApplicationService.Current.State dictionary to iso storage. Serializing the dictionary was an interesting coding exercise, doing final testing, looks good so far. So I should have everything covered, if the user knows that they will be doing a lot on their phone, they could just save the state, and restore it later. And not rely on the OS doing what it wants.





    Was ready to post, and saw your post so I added this;


    Hitting the start stops it, back key goes back to resuming. If you hit start, and re-launch the emulator hangs on the splash screen.




    Some additional comments. I don’t think you can debug this problem without the debugger, since you can’t force tombstoning. Running using the debugger and checking tombstone on deactivation, locks every time.


    If you run just from the emulator then the app is FASed, and no issues. Really need a way to test tombstoning on a phone.


    Thursday, April 05, 2012 3:56 PM
  • Mark:

    As Orencosoft mentions, the only way I know of to test the natural tombstoning codepath in Mango is to use the debugger.  If you have other suggestions, I'm all ears.

    And no, hitting F5 does not cause the app to resume.  Mainly because the debugger has not broken into the app.  It's just sitting there attached, so telling it to go doesn't change anything.

    If I had to guess, I'd say that there are two things going on:

    1) Something ResolveHostNameAsync does is preventing the process from either terminating or restarting.  Maybe it starts a native thread which blocks, or some such?
    2) Something in the OS is not timing out waiting for the process to terminate or restart.

    The combination of the two leads to a hang in this scenario.

    Mark - it would be great if you could repro the scenario and see if maybe a fix could be included in a future release of the OS?  This is a pretty bad bug.
    Thursday, April 12, 2012 8:07 PM
  • Thanks Cat's Paw,

    I reproduced this using the emulator (it occurs with the project's Debug properties "Tombstone upon deactivation while debugging" checkbox set), and will report this to the development group. 

    I will post any news back to this thread.

    I could not find this particular problem reported in our internal bug/issues database.

    Friday, April 13, 2012 4:05 PM
  • Hi,

    first up, thank you for saving me hours of (maybe fruitless) searching. At least I now know where the problem is.

    Secondly, is there anything new here? Do we know if this problem is just in the debugger, or does it happen if the app is tombstoned on a device?

    • Proposed as answer by Nick.WangBo Monday, September 10, 2012 2:11 AM
    • Unproposed as answer by Nick.WangBo Monday, September 10, 2012 2:11 AM
    Monday, June 04, 2012 9:14 PM
  • I reproduced this in a device too. 

    To my knowledge there are no new developments around this issue.
    I will let you know if there are any changes.


    Monday, June 04, 2012 9:36 PM
  • OK, thanks. I have just removed the call to ResolveHostNameAsync for now. I switched to using the TransferStatus for a background transfer to let the user know why nothing is happening (before I was just disabling the download button with a note along the lines of 'A WiFi connection is required...'

    Anyway, solved for now... but this is a pretty nasty bug that should be fixed as soon as possible.
    Wednesday, June 06, 2012 10:52 AM
  • Hi, this issure have resloved in Windows Phone 8 SDK.
    Tuesday, October 16, 2012 10:31 AM