Приложение Windows Phone 7.1 завершает работу без каких-либо исключений

В настоящее время работает над многопоточным приложением WP 7.1.1 и немногим более половины случаев, когда приложение завершает работу на «начальной фазе» без выдачи каких-либо исключений. Он просто заканчивается тем, что все потоки возвращают 0x0 и не вводят никаких событий закрытия / выхода / выхода.

...
The thread '<No Name>' (0xfde00d2) has exited with code 0 (0x0).
The thread '<No Name>' (0xe860116) has exited with code 0 (0x0).
The thread '<No Name>' (0xfdf00c6) has exited with code 0 (0x0).
The thread '<No Name>' (0xf8d012e) has exited with code 0 (0x0).
The thread '<No Name>' (0xfd5010e) has exited with code 0 (0x0).
The thread '<No Name>' (0xfbc011a) has exited with code 0 (0x0).
The thread '<No Name>' (0xf9900ee) has exited with code 0 (0x0).
The program '[268042506] UI Task: Managed' has exited with code 0 (0x0).
EOL 

Что именно означает «начальная фаза»? Я профилировал приложение с помощью «Анализ производительности Windows Phone», и вместе с некоторыми отладочными сообщениями и некоторыми журналами, по моим оценкам, это происходит примерно через 3-4 секунды после запуска. В этот момент графический интерфейс пользователя уже виден на очень короткое время.

Я почти уверен, что проблема возникает из-за следующего звонка:

private static List<MyEntries> EntriesLoad()
{
    using(var context = Context.ReadOnly) // <- works
    {
        return context.MyEntries.Where(m => !m.Deleted).OrderBy(m => m.Name).ToList(); // <- problem
    }
}

private async void EntriesReload()
{
    EntriesLoaded = false; // <- called
    var entries = await TaskEx.Run<List<MyEntries>>(EntriesLoad); // <- called
    EntriesLoaded = true; // <- only get's called 50% of the time/ otherwise app quits
}

Чтобы предотвратить любые проблемы многопоточности с DataContext, при каждом вызове создается новый контекст:

public static Context ReadOnly 
{
    get { return new Context(ConnectionReadOnly); }
}

Я даже попробовал BackgroundWorker и ThreadPool вместо Async CTP 3, но с тем же эффектом. Я знаю, что задавались очень похожие вопросы многие раз до, но я просто не смог найти решение своей проблемы. Есть ли способ / программа, с помощью которой я мог бы найти точный метод (причину, место), вызывающий исключение? Есть ли ограничения на количество создаваемых потоков? Можно ли таким образом безопасно использовать DataContext?

Ваша помощь очень ценится.


person UnclePaul    schedule 31.05.2012    source источник


Ответы (2)


Когда метод async void генерирует исключение, это исключение передается прямо в «контекст» - в данном случае контекст пользовательского интерфейса.

Итак, даже если вы вызываете EntriesReload в _3 _ / _ 4_, вы никогда не поймаете какое-либо исключение, вызванное EntriesReload.

async методы всегда должны возвращать Task или Task<TResult>, если только они не должны возвращать void (например, async обработчики событий).

Затем, когда вы вызываете EntriesReload, await результат. Это не устранит сбой, но позволит увидеть исключение.

person Stephen Cleary    schedule 31.05.2012

Спасибо, Стивен, за ответ. Мне все еще не удалось обнаружить никаких исключений из предложенных вами изменений, однако ваш ответ помог мне лучше понять, что происходит за кулисами. Так что еще раз спасибо за это.

Наконец, мне удалось избавиться от всех "тихих" исключений, из-за которых приложение почти в половине случаев закрывалось случайным образом вскоре после запуска. К моему удивлению, это, возможно, не было вызвано каким-либо моим кодом, а могло произойти из класса DataContext. Как придешь? В моем приложении я использовал две разные строки подключения:

/* with DeferredLoadingEnabled = false; ObjectTrackingEnabled = true; */
private const string Connection = "Data Source=isostore:/MyDatabase.sdf;max buffer size=1024;max database size=512;";

/* with DeferredLoadingEnabled = false; ObjectTrackingEnabled = false; */
private const string ConnectionReadOnly = Connection + "File Mode = read only;";

Исключения возникали только во время (а не после, до или во время присвоения возвращаемых значений) операций чтения в DataContext, который использовал строку подключения ReadOnly. Избавившись от свойства ReadOnly и не изменив ни одной строчки кода, я полностью решил мои проблемы. Так может быть проблема с потоками в DataContext или в одной из библиотек? Я не могу реально оценить влияние на производительность воздержания от подключений ReadOnly, но поскольку я получаю только небольшой объем данных и использую DataContext очень атомарно, я не возражаю против возможных накладных расходов в моем конкретный вариант использования.

person UnclePaul    schedule 07.06.2012