2015-02-18 4 views
-1

Я пытаюсь сортировать проблему, возникшую при обновлении некоторых серверов с Windows Server 2008 до 2012 года. Это приложение .NET 3.5 C# WinForms, которое закручивает поток для запуска некоторых потенциально очень длительные хранимые процедуры.Unresponsive GUI в новой операционной системе

Фоновый поток устанавливается следующим образом:

t = new System.Threading.Thread(new System.Threading.ThreadStart(StartProcess)); 
t.IsBackground = true; 
t.Priority = System.Threading.ThreadPriority.BelowNormal; 
t.Start(); 

StartProcess() выстреливает определенный статус обновлений обратно в поток пользовательского интерфейса, которые работают нормально, а затем в конце концов, попадает в вызов, как это:

// cmd is configured with a CommandTimeout value of 0 
using(SqlDataAdapter da = new SqlDataAdapter(cmd)) 
{ 
    DataSet ds = new DataSet(); 

    da.Fill(ds); 

    return ds; 
} 

Звонок Fill() работает нормально для коротких коротких скрестов, но если используется длительное время (время выполнения в часах), графический интерфейс заканчивается тем, что перестает отвечать через 15-45 минут. Связанный sproc завершится, но GUI не будет обновляться снова.

Какая дополнительная информация потребуется для диагностики проблемы? Есть ли какая-то неотъемлемая разница между двумя версиями ОС, чтобы сделать эту реализацию проблематичной?

Следует также упомянуть, что это приложение будет работать нормально при запуске в режиме отладки через Visual Studio; это только при запуске развернутой версии версии релиза, которая зависает. Я попытался создать простое приложение WinForms, которое вызывает sproc, который просто использует WAITFOR для имитации 50-минутного времени выполнения, но это не проявляет невосприимчивости, наблюдаемой в реальном приложении.

+1

Почему вы сортируете 'da.Fill' в потоке пользовательского интерфейса? Вот где работает БД. Пусть это происходит асинхронно или в отдельном потоке и возвращает только подготовленные данные, установленные обратно в поток пользовательского интерфейса. – Luaan

+0

'da.Fill' не находится в потоке пользовательского интерфейса, это происходит в потоке' t'. –

+1

Звучит как условие гонки, которое каким-то образом не срабатывало под Win 2k8 и не по какой-либо причине (оптимизации?) Происходит в Visual Studio. Не можете ли вы подключить отладчик к процессу при работе за пределами Visual Studio? (в VS, Debug -> Attach to Process), когда он выглядит невосприимчивым? – Jcl

ответ

1

Благодаря большому количеству поисковых запросов и подсказок, содержащихся в комментариях, я считаю, что я смог идентифицировать и решить проблему.

Самая большая помощь была в этом блоге MSDN post, который точно соответствовал моему опыту.

В принципе, мне нужно было прикрепить windbg к моему процессу, когда его повесили, и через windbg я смог идентифицировать свою проблему как проблему OnUserPreferenceChanged. Я прикрепляю Windbg снова мое приложение, прежде чем он висел и выполнил следующие Windbg команды:

!name2ee System_Windows_Forms_ni System.Windows.Forms.Application+MarshalingControl..ctor 
bp [JITTED_ADDRESS_FROM !name2ee CALL]".echo MarshalingControl creation detected. Callstack follows.;!clrstack;.echo" 

И я обнаружил, что форма заселяется/отображаемой через t нити. Я завернул вызов, который сделал это в тесте InvokeRequired, и теперь моя проблема исчезла.

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