2012-05-31 12 views
1

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

... 
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 секунды после начала. По его мнению, GUI уже заметен в течение очень короткого промежутка времени.

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

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, но с тем же эффектом. Я знаю, что очень похожие вопросы были заданы many times before, но я просто не мог найти решения по моей проблеме. Есть ли способ/программа, я могу найти точный метод (причина, loc), который вызывает исключение? Существуют ли какие-либо ограничения на то, сколько потоков может быть создано? Можно ли безопасно использовать DataContext таким образом?

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

ответ

0

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

Наконец-то мне удалось избавиться от всех «тихих» исключений, которые вызвали приложение - почти в половину времени - случайным образом прекратились вскоре после начала. К моему удивлению, это, возможно, не вызвано каким-либо моим кодом, но может возникнуть в классе 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;"; 

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

2

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

Так что - даже если вы звоните EntriesReload в try/catch - вы никогда не будете ловить любое исключение, по EntriesReload.

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

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

Смежные вопросы