Есть служба в ней работает порядка 20 потоков порожденных new Thread.
В потоке работает такой код
while (true)
{
doSmth();//запросы к БД
Thread.Sleep(5000);
}
Внезапно исчезает один поток (не отображается в логах).
Пока предположение, что у потока упал приоритет (винда понизила?) и теперь у него нет шансов получить время для работы.
Возможно ли такое?

Здравствуйте, Qt-Coder, Вы писали:

QC>Внезапно исчезает один поток (не отображается в логах).
QC>Пока предположение, что у потока упал приоритет (винда понизила?) и теперь у него нет шансов получить время для работы.
QC>Возможно ли такое?

Нет. Он может быть неактивен, но это не причина для его смерти.

Поток может исчезнуть по одной из 2 причин

1. Сам закончился. В том числе вследствие возникшего в нем и перехваченного исключения.
2. Кто-то ему TerminateThread сделал.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Поток может исчезнуть по одной из 2 причин

PD>1. Сам закончился. В том числе вследствие возникшего в нем и перехваченного исключения.
PD>2. Кто-то ему TerminateThread сделал.

Штож, пойду искать причину.

QC>Внезапно исчезает один поток (не отображается в логах).

А он точно не висит в каком-то месте?
Если возможно, то следует исследовать живой процесс или дамп памяти через Debug Diagnostic Tool (DebugDiag) или WinDbg.

Здравствуйте, m2user, Вы писали:

M>Если возможно, то следует исследовать живой процесс или дамп памяти через Debug Diagnostic Tool (DebugDiag) или WinDbg.

Или через Process Explorer. (<Select Process> — Properties — Threads)

Здравствуйте, m2user, Вы писали:

QC>>Внезапно исчезает один поток (не отображается в логах).

M>А он точно не висит в каком-то месте?
M>Если возможно, то следует исследовать живой процесс или дамп памяти через Debug Diagnostic Tool (DebugDiag) или WinDbg.

Он точно не вышел из цикла while (true), т.к. после выхода стоит логгирование. Где-то заблудился в коде, наверное, надо искать, может на запросе к БД завис, хотя там стоят таймауты. Завис наглухо, обнаружили только через 5 суток.
Отладить нельзя, просто перезапустили службу.

Здравствуйте, Qt-Coder, Вы писали:

QC>Он точно не вышел из цикла while (true), т.к. после выхода стоит логгирование. Где-то заблудился в коде, наверное, надо искать, может на запросе к БД завис, хотя там стоят таймауты. Завис наглухо, обнаружили только через 5 суток.
QC>Отладить нельзя, просто перезапустили службу.

Если еще раз произойдет, запусти Process Explorer и посмотри у этого потока Stack. Может, что-то удастся понять.

PD>1. Сам закончился. В том числе вследствие возникшего в нем и перехваченного исключения.

Внутри потока случилось исключение и его не обработали. Но автор говорит есть обработчик с логгированием. Тогда возможно:
1a. StackOverflowException — проскочит мимо обработчика. Вот только не уверен не убьет ли он потом весь процесс. Вроде нет?
1b. OutOfMemoryException — залетит в обработчик, но при попытке залоггировать опять памяти может не хватить.

Если Windows можно попытаться какие-то концы в Eventlog поискать.

M>>Если возможно, то следует исследовать живой процесс или дамп памяти через Debug Diagnostic Tool (DebugDiag) или WinDbg.

PD>Или через Process Explorer. (<Select Process> — Properties — Threads)

Дамп можно и через PE снять (при этом очень желательно чтобы разрядность (32/64) процесса PE совпадала с разрядностью проблемного процесса).
А вот всесторонне исследовать дамп лучше уже через специализированный инструмент.
Там же можно и managed/unmanaged стек посмотреть, и состояние переменных. И живой процесс уже не нужен (можно перезапускать).

Здравствуйте, m2user, Вы писали:

M>Дамп можно и через PE снять (при этом очень желательно чтобы разрядность (32/64) процесса PE совпадала с разрядностью проблемного процесса).

Насколько я понимаю, об этом он сам заботится. При запуске procexp запускается еще и procexp64, а там они уже как-то сами разбираются, каким процессом кому заниматься.

M>>Дамп можно и через PE снять (при этом очень желательно чтобы разрядность (32/64) процесса PE совпадала с разрядностью проблемного процесса).
PD>Насколько я понимаю, об этом он сам заботится. При запуске procexp запускается еще и procexp64, а там они уже как-то сами разбираются, каким процессом кому заниматься.

Да, скорее всего Вы правы. Я с Windows Task Manager попутал, он ведь тоже умеет снимать дампы.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Насколько я понимаю, об этом он сам заботится. При запуске procexp запускается еще и procexp64, а там они уже как-то сами разбираются, каким процессом кому заниматься.

Task Manager виндовый сам дампы снимать умеет.

Здравствуйте, syrompe, Вы писали:

PD>>1. Сам закончился. В том числе вследствие возникшего в нем и перехваченного исключения.

S>Внутри потока случилось исключение и его не обработали. Но автор говорит есть обработчик с логгированием. Тогда возможно:
Необработанное обрушило бы весь процесс, а не один поток, остальные потоки весело булькают.

Здравствуйте, Qt-Coder, Вы писали:


QC>Необработанное обрушило бы весь процесс.

Нифига, в службе проглатывается. Сам видел и охренел.

Здравствуйте, Qt-Coder, Вы писали:

QC>Необработанное обрушило бы весь процесс, а не один поток, остальные потоки весело булькают.

Если процесс является службой (например ASP.NET), то он от этого не упадёт. У вас же процесс не завершается, если например в рамках обработки запроса в одном из потоков произошло необработанное исключение.
Вот если в консольном приложении такое сделать, то да, процесс будет завершён.

4>Если процесс является службой (например ASP.NET), то он от этого не упадёт. У вас же процесс не завершается, если например в рамках обработки запроса в одном из потоков произошло необработанное исключение.
4>Вот если в консольном приложении такое сделать, то да, процесс будет завершён.

Вроде ТС говорит про Windows Service, а не про ASP.NET web service.

Здравствуйте, m2user, Вы писали:

4>>Если процесс является службой (например ASP.NET), то он от этого не упадёт. У вас же процесс не завершается, если например в рамках обработки запроса в одном из потоков произошло необработанное исключение.
4>>Вот если в консольном приложении такое сделать, то да, процесс будет завершён.

M>Вроде ТС говорит про Windows Service, а не про ASP.NET web service.
Так и есть.

Здравствуйте, m2user, Вы писали:

M>Вроде ТС говорит про Windows Service, а не про ASP.NET web service.

ASP.NET приведён в качестве примера, т.к. Windows Service это тоже служба, и логика обработки потоков у них идентичная.

M>>Вроде ТС говорит про Windows Service, а не про ASP.NET web service.
4>ASP.NET приведён в качестве примера, т.к. Windows Service это тоже служба, и логика обработки потоков у них идентичная.

Я не сильно разбираюсь в том, как работает ASP.NET.
Но что касается Windows Service, то от обычного консольного приложения он по сути отличается только обработкой RPC запросов от Service Control Manager и регистрацией в реестре.
И от неперехваченных исключений падает точно также, как любое консольное приложение.

Полагаю, что ТС это может проверить несложным практическим экспериментом.

Здравствуйте, m2user, Вы писали:

M>>>Вроде ТС говорит про Windows Service, а не про ASP.NET web service.
4>>ASP.NET приведён в качестве примера, т.к. Windows Service это тоже служба, и логика обработки потоков у них идентичная.

M>Я не сильно разбираюсь в том, как работает ASP.NET.
M>Но что касается Windows Service, то от обычного консольного приложения он по сути отличается только обработкой RPC запросов от Service Control Manager и регистрацией в реестре.
M>И от неперехваченных исключений падает точно также, как любое консольное приложение.

M>Полагаю, что ТС это может проверить несложным практическим экспериментом.

У меня было необработанное исключение в потоке, который создался в методе OnStart() сервиса через new Thread(() => {...}).Start(), а именно ParseException. Так вот это было тихо проглочено, чем вызвало 3 часа головной боли в дебагере.

Полагаю, что вы можете убедиться в этом с помощью несложного практического эксперимента.