Общие диалоги в Windows Server 2008 R2: сбой в GetOpenFileName

У нас есть большое приложение, написанное на C ++, работающее на Windows Server 2003 и Windows Server 2008 R2. Он использует API GetOpenFileName для вызова диалогового окна «Открыть файл» для выбора видеофайла.

Мы видим, что в Windows Server 2008 R2 иногда происходит сбой в диалоговом окне «Открыть файл». Основной поток графического интерфейса ожидает рабочий поток, а рабочий поток получает исключение нарушения прав доступа. Трассировка стека выглядит следующим образом:

linkinfo.dll!_IsValidLinkInfo@4()
shell32.dll!LinkInfo_LoadFromStream()  + 0x7d bytes
shell32.dll!CShellLink::_LoadFromStream()  + 0x14b bytes
shell32.dll!CShellLink::Initialize()  + 0x1a bytes
shell32.dll!InitializeFileHandlerWithStream()  + 0xc4 bytes
shell32.dll!CFileSysItemString::HandlerCreateInstance()  + 0x13b bytes
shell32.dll!CFileSysItemString::LoadHandler()  - 0x9f1d bytes
shell32.dll!CFSFolder::_CreatePerInstanceDefExtIcon()  + 0x9b bytes
shell32.dll!CFSFolder::_CreateDefExtIcon()  + 0xb6 bytes
shell32.dll!CFSFolder::s_GetExtractIcon()  + 0x1e bytes
shell32.dll!CFSFolder::_BindHandler()  - 0xd759 bytes
shell32.dll!CFSFolder::GetThumbnailHandler()  + 0x51 bytes
shell32.dll!_CreateThumbnailHandler()  + 0x61 bytes
shell32.dll!CShellItem::BindToHandler()  - 0x20a93 bytes
shell32.dll!_GetExtractIconW@16()  + 0x63 bytes
shell32.dll!_GetILIndexFromItem()  + 0x5f bytes
shell32.dll!_SHGetIconIndexFromPIDL@20()  - 0x3857d bytes
shell32.dll!CFSFolder::GetIconOf()  + 0xa57c3 bytes
shell32.dll!_SHGetIconIndexFromPIDL@20()  + 0x24 bytes
shell32.dll!_SHIconIndexFromPIDL@16()  + 0x3d bytes
shell32.dll!CRegFolder::GetIconOf()  + 0x10a892 bytes
shell32.dll!_SHGetIconIndexFromPIDL@20()  + 0x24 bytes
shell32.dll!_SHIconIndexFromPIDL@16()  + 0x3d bytes
explorerframe.dll!CNscIconTask::_Extract()  + 0x1f bytes
explorerframe.dll!CNscOverlayTask::InternalResumeRT()  + 0x31 bytes
explorerframe.dll!CRunnableTask::Run()  + 0xa2 bytes
shell32.dll!CShellTask::TT_Run()  + 0x5b bytes
shell32.dll!CShellTaskThread::ThreadProc()  + 0x99 bytes
shell32.dll!CShellTaskThread::s_ThreadProc()  + 0x1b bytes
shlwapi.dll!_ExecuteWorkItemThreadProc@4()  + 0xe bytes
ntdll.dll!_RtlpTpWorkCallback@8()  + 0xdf bytes
ntdll.dll!_TppWorkerThread@4()  - 0x1185 bytes
kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

Похоже, что ряд других людей столкнулись с аналогичными проблемами: MSDN поток с 2011 года.

«У меня та же ситуация, что при открытии общего диалога (8R2) происходит сбой приложения. Иногда это помогает перезапустить приложение и попробовать его снова… иногда нет. Так как это происходит для пары приложений от различных поставщиков, это больше скорее всего, проблема общего диалога «.

«Я хочу сказать, что у нас возникла та же проблема с машиной 2008 R2. Это может быть любая программа (и я видел это однажды в Notepad.exe). Когда вы смотрите на средство просмотра событий, вы видите, что сбой происходит в разных модулях, которые вызываются общим диалоговым окном. Это происходит в 32-битных и 64-битных программах. Это происходит не в 100% случаев, а в 50%. когда и почему это происходит «.

Наша гипотеза состоит в том, что диалоговое окно «Открыть файл» пытается получить некоторую миниатюрную информацию из видеофайла, но происходит сбой видеодекодера.

Кто-нибудь еще сталкивался с этой проблемой? Если да, то смогли ли вы выяснить причину? Знаете ли вы что-нибудь о том, почему IsValidLinkInfo может получить нарушение прав доступа?

Есть ли обходные пути, которые мы могли бы применить здесь? Мы планируем попытаться удалить сопоставление файлов для этого конкретного типа файлов (.ts). Можно ли как-то сказать диалоговому окну «Открыть файл» не создавать эскизы?

1

Решение

Обновить:

Мы нашли другой поток на ServerFault сообщение о похожей проблеме («Обычно она вылетает, когда вы нажимаете Файл / Открыть или Файл / Сохранить, но не каждый раз»). Другой пользователь (PG) смог решить проблему, исключив приложение из Data Execution Prevention по рекомендации Microsoft.

Мы проверили параметр «Предотвращение выполнения данных» и обнаружили, что для него установлено «Включить DEP для всех программ и служб, кроме выбранных». После изменения значения «Включить DEP только для основных программ и служб Windows» проблема больше не возникает.

0

Другие решения

Других решений пока нет …