Приложение зависает вне Visual Studio. Начиная с Visual Studio, он работает
медленно меня перегружает...
У меня есть огромное приложение с потоками, таймерами, invoke (не BeginInvoke, так что это синхронно) и Application.DoEvents.
Слишком много сообщений, и я не знаю, где проблема на самом деле.
Каждый мой метод находится внутри try catch. Каждый лог регистрируется.
Если я запускаю свое приложение из Visual Studio (F5) или при профилировании его через Ants нет проблемы. Приложение работает через несколько дней.
Но как только я запускаю ту же версию отладки через Windows Explorer, она замерзает каждые несколько часов. Он замораживается без каких-либо исключений или около того.
Если я прикреплю визуальную студию к этому приложению и сломаю ее, она остановится на Application.Run(новый Form1());
Я действительно смущен и понятия не имею, чтобы исправить это.
Это приложение winnet 3.5.
Похоже, здесь висит одна нить:
if (grabber.InvokeRequired)
{
Console.WriteLine("grabber.InvokeRequired");
this.Invoke((MethodInvoker) delegate { grabber.Navigate("http://www.google.de"); }); // <-- hang
}
else
{
grabber.Navigate(ig.StartUrl);
}
этот фрагмент является частью события таймера
_timeout = new System.Timers.Timer(10000);
_timeout.Elapsed += new ElapsedEventHandler(OnWatchDogBark);
Edit
Образец для DoEvents(). Это находится в блокировке() и в вызове
grabber.DocumentCompleted -= grabber_DocumentCompleted;
grabber.Navigate("http://www.google.de");
while (grabber.ReadyState != WebBrowserReadyState.Complete)
{
timeout--;
Application.DoEvents();
Thread.Sleep(200);
if (timeout < 0)
{
timeout = 50;
grabber.Navigate("http://www.google.de");
}
}
В настоящее время я использую System.Windows.Forms.Timer и некоторые блокировки, но улучшения нет.
Хорошо, я использовал WinDbg для получения информации
Изменить: 14.06.2012
! Нити
PreEmptive GC Alloc Lock
ID OSID ThreadOBJ State GC Context Domain Count APT Exception
0 1 37ec 007cab18 6020 Enabled 00000000:00000000 007c8510 0 STA System.ArgumentException (02762ba8)
2 2 85b8 007d7c38 b220 Enabled 00000000:00000000 007c8510 0 MTA (Finalizer)
XXXX 3 0 06e9f548 9820 Enabled 00000000:00000000 007c8510 0 Ukn
21 5 3464 0d6dc598 200b020 Enabled 28cb5820:28cb5fe8 007c8510 0 MTA
22 6 62b0 0d6db9e0 200b220 Enabled 00000000:00000000 007c8510 0 MTA
23 7 8e58 0d6db5f8 80a220 Enabled 00000000:00000000 007c8510 0 MTA (Threadpool Completion Port)
XXXX 4 0 06f62d40 1801820 Enabled 00000000:00000000 007c8510 0 Ukn (Threadpool Worker)
XXXX f 0 132a3290 1801820 Enabled 00000000:00000000 007c8510 0 Ukn (Threadpool Worker)
XXXX 10 0 132a3678 1801820 Enabled 00000000:00000000 007c8510 0 Ukn (Threadpool Worker)
XXXX e 0 132a26d8 1801820 Enabled 00000000:00000000 007c8510 0 Ukn (Threadpool Worker)
XXXX 9 0 0d6db210 1801820 Enabled 00000000:00000000 007c8510 0 Ukn (Threadpool Worker)
! DLK
Examining SyncBlocks...
Scanning for ReaderWriterLock instances...
Scanning for holders of ReaderWriterLock locks...
Scanning for ReaderWriterLockSlim instances...
Scanning for holders of ReaderWriterLockSlim locks...
Examining CriticalSections...
Could not find symbol ntdll!RtlCriticalSectionList.
No deadlocks detected.
Ответы
Ответ 1
Может быть возможным Тупик в фоновом потоке.
Попробуйте посмотреть другие потоки, которые могут заблокировать ваше приложение.
Toolbar -> Debug -> Windows -> Threads
http://msdn.microsoft.com/en-us/library/w15yf86f.aspx
Должно быть несколько потоков, и если вы дважды щелкните по нему, вы увидите строку, в которой она останавливает ваше приложение.
И если вы используете эту строку в своем коде:
Control.CheckForIllegalCrossThreadCalls = false;
Установите значение true. Возможной причиной мертвых замков являются элементы управления доступом к потоку.
Вместо того, чтобы писать это из потоков backgroud.
button1.Text = "hello"
напишите это.
this.Invoke(() => button1.Text = "hello");
Ответ 2
Если это замерзает, вы, вероятно, смотрите на тупик. Одним из лучших способов найти тупик является использование дампа сбоя и sosex.
Вот хорошая статья об использовании этой техники (это asp.net, но применяются те же принципы): http://blogs.msdn.com/b/tess/archive/2010/04/27/debugging-a-classic-readerwriterlock-deadlock-with-sosex-dll.aspx
пусть приложение запустится до тех пор, пока оно не зависает, и возьмите дамп: http://blogs.msdn.com/b/tess/archive/2006/10/16/net-hang-debugging-walkthrough.aspx
Ответ 3
Вызов является опасным и может легко вызвать взаимоблокировки неожиданными способами, которые я рекомендовал бы заменить
this.Invoke((MethodInvoker)...
с
this.BeginInvoke((MethodInvoker)...
который не будет блокировать вызывающего абонента и, вероятно, устранит проблему.
отредактируйте, если вам это не понадобится, вам нужно будет подождать до тех пор, пока он не будет заблокирован, а затем используйте windbg, чтобы посмотреть, почему вы зашли в тупик.
Ответ 4
При запуске из VS он будет вводить поток отладчика, который изменяет некоторую маршрутизацию сообщений. У вас может возникнуть проблема с блокировкой Invoke(...)
на то, что ожидает сообщения в очереди, но в отладчике сообщения win обрабатываются в другом порядке.
IIUC вам не нужны блокировки с System.Windows.Forms.Timer, потому что он использует насос сообщений о выигрышах, поэтому события таймера всегда обрабатываются в потоке графического интерфейса (если только что-то в вашем приложении не запускает код на TheadPool или в выделенные фоновые потоки).
Итак, ничто в вашем примере кода не связано с потоковой обработкой, если только веб-браузер не запускает свои события в фоновом потоке (в этом случае POST они возвращаются к потоку пользовательского интерфейса, BeginInvoke()
). После того, как все управление приложениями, запущенное в основном потоке пользовательского интерфейса, удалите блокировки (в качестве вспомогательного средства для отладки). Пожалуйста, напишите больше информации о фоновой обработке и любых результатах на сегодняшний день.