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

N>>>>а зачем он нужен? я ведь не использую СОМ.
O>>>Затем что нужен. Читать надо мсдн внимательно. И до конца: http://msdn.microsoft.com/en-us/library/bb762153(VS.85).aspx
N>>К сожалению и это не помогло
O>минимальный код в студию
Попробую воспроизвести на минимальном приложении, если удастся, выложу код.

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

PD>Сразу "здыхать" программа сама не может, это сложный процесс. Вот убить ее можно сразу.

Может-может. А вообще вот хорошо расписано: http://www.rsdn.ru/forum/cpp/3913781.1.aspx

Автор: remark
Дата: 10.08.10

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

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

PD>>Сразу "здыхать" программа сама не может, это сложный процесс. Вот убить ее можно сразу.

Ops>Может-может. А вообще вот хорошо расписано: http://www.rsdn.ru/forum/cpp/3913781.1.aspx

Автор: remark
Дата: 10.08.10

Все это мне хорошо известно. Но, говоря о том, что не может, я вовсе не это имел в виду. Я имел в виду процесс завершения приложения при возникновении критической ошибки. Он подробно рассмотрен у Соломона — Руссиновича.

O>>>>Затем что нужен. Читать надо мсдн внимательно. И до конца: http://msdn.microsoft.com/en-us/library/bb762153(VS.85).aspx
N>>>К сожалению и это не помогло
O>>минимальный код в студию
N>Попробую воспроизвести на минимальном приложении, если удастся, выложу код.
и заодно бы в крэшдамп взглянули бы

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

O>>>минимальный код в студию
N>>Попробую воспроизвести на минимальном приложении, если удастся, выложу код.
O>и заодно бы в крэшдамп взглянули бы

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

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

O>и заодно бы в крэшдамп взглянули бы

вот callstack crashdump-a:

ntdll!KiFastSystemCallRet
ntdll!ZwWaitForMultipleObjects+0xc
kernel32!WaitForMultipleObjectsEx+0x11d
user32!RealMsgWaitForMultipleObjectsEx+0x13c
user32!MsgWaitForMultipleObjects+0x1f
shell32!SHProcessMessagesUntilEventEx+0x51
shell32!CShellExecute::_RunThread+0x6e
shell32!CShellExecute::ExecuteNormal+0x8e
shell32!ShellExecuteNormal+0x33
shell32!ShellExecuteExW+0x62
WARNING: Stack unwind information not available. Following frames may be wrong.
MyApp+0x1e695
MyApp+0x1b2bf
mfc90u+0x6ade3
MyApp+0x5b12b
kernel32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x23
ntdll!_RtlUserThreadStart+0x1b

Как видно — обрывается на ntdll!KiFastSystemCallRet, но в самом креше пишет что имя модуля Secur32.dll.

N>Как видно — обрывается на ntdll!KiFastSystemCallRet, но в самом креше пишет что имя модуля Secur32.dll.

Пардон это первый поток, в другом потоке callstack вот-такой:

secur32!CallSPM+0x1a
secur32!SecpGetUserName+0x98
secur32!GetUserNameExW+0x29
secur32!GetUserNameExA+0x58
advapi32!GetUserNameA+0x15
urlmon!CSharedMem::Init+0x54
urlmon!CUrlZoneManager::Initialize+0x39
urlmon!InternetCreateZoneManager+0x87
urlmon!CSecurityManager::EnsureZoneManager+0x1a
urlmon!CSecurityManager::ProcessUrlActionEx2Internal+0x6d
urlmon!CSecurityManager::ProcessUrlAction+0x10e
shlwapi!ZoneCheckUrlExCacheW+0xe5
shlwapi!ZoneCheckUrlExW+0x24
shell32!CExecuteApplication::_ZoneCheckFile+0x40
shell32!CExecuteApplication::_VerifyZoneTrust+0x2d
shell32!CExecuteApplication::_VerifyExecTrust+0x41
shell32!CExecuteApplication::Execute+0x27
shell32!CExecuteAssociation::_DoCommand+0x70
shell32!CExecuteAssociation::_TryApplication+0x3e
shell32!CExecuteAssociation::Execute+0x30

а в 3-тьем, такой:

ntdll!KiFastSystemCallRet
ntdll!ZwWaitForWorkViaWorkerFactory+0xc
ntdll!TppWorkerThread+0x1f6
kernel32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x23
ntdll!_RtlUserThreadStart+0x1b

Это получается GetUserName навернулся, крута
hack: попробуйте добавить флажок SEE_MASK_NOZONECHECKS
todo: разберитесь че оно у вас там падает, такого быть не должно

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

O>Это получается GetUserName навернулся, крута
O>hack: попробуйте добавить флажок SEE_MASK_NOZONECHECKS
попробовал, да, действительно с этим флагом все ок, т.е. креш-а нету.

O>todo: разберитесь че оно у вас там падает, такого быть не должно
дык в том то и дело, что я бы сюда не писал, если бы знал КАК разобраться..

O>>todo: разберитесь че оно у вас там падает, такого быть не должно
N>дык в том то и дело, что я бы сюда не писал, если бы знал КАК разобраться..
Нуна смотреть что за параметры пришли в GetUserNameA если они невалидны — почему невалидны, если валидны — почему мог свалиться secur32!CallSPM+0x1a

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

O>Нуна смотреть что за параметры пришли в GetUserNameA если они невалидны — почему невалидны, если валидны — почему мог свалиться secur32!CallSPM+0x1a
сорри, но можете подсказать, как смотреть параметры?

O>>Нуна смотреть что за параметры пришли в GetUserNameA если они невалидны — почему невалидны, если валидны — почему мог свалиться secur32!CallSPM+0x1a
N>сорри, но можете подсказать, как смотреть параметры?
В windbg начать следует с kv ffff, параметры будут в 3-5 столбцах. Но если вы этого не знаете — скорее всего не разберетесь чо там дальше. Проще будет найти баг методом научного тыка деления отрезка пополам — минимизации кода пока баг не пройдет

А еще мона покопаться вот тут: http://www.google.by/search?hl=ru&q=secur32!CallSPM%2B0x1a&aq=f&aqi=&aql=&oq=

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

O>>>Нуна смотреть что за параметры пришли в GetUserNameA если они невалидны — почему невалидны, если валидны — почему мог свалиться secur32!CallSPM+0x1a
N>>сорри, но можете подсказать, как смотреть параметры?
O>В windbg начать следует с kv ffff, параметры будут в 3-5 столбцах. Но если вы этого не знаете — скорее всего не разберетесь чо там дальше. Проще будет найти баг методом научного тыка деления отрезка пополам — минимизации кода пока баг не пройдет
и все-таки, может где-то можно почитать об анализе дампа, а конкретнее — вытягивание параметров со стека?

Сколько можно флудить? Ответ уже выдан — повреждение данных внутри программы. Что ещё здесь можно обсуждать? Пусть основатель ветки ищет ошибку в своём коде. Советую ветку закрыть.

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

S>Сколько можно флудить? Ответ уже выдан — повреждение данных внутри программы. Что ещё здесь можно обсуждать? Пусть основатель ветки ищет ошибку в своём коде. Советую ветку закрыть.
Мда. Уважаемый, вам что, эта ветка жить мешает? Согласен, два моих последних поста не очень подходят к теме топика, но не так уж и далеко в плане последовательности решения проблемы (может кто-нибудь еще потом спасибо скажет за продолжение темы), и посылать искать ошибку в коде, после того как я обратился сюда имеено потому что НЕ нашел ее, ИМХО, неуважительно. Потому как, откуда вы знаете сколько времени я провел за исканием вышеупомянутой ошибки?