| Сейчас на форуме: (+5 невидимых) |
 |
eXeL@B —› Дневники и блоги —› Баги в операционных системах и окружении |
| Посл.ответ | Сообщение |
|
|
Создано: 23 июля 2009 18:26 · Личное сообщение · #1 Этот блог может быть полезен для разработчиков низкоуровневого софта и драйверов. Сюда я буду писать о багах в Windows, BIOS, драйверах, и прочем окружении, в котором может работать наш софт. Это могут быть различные особенности поведения API, ошибки в документации, и прочие грабли, на которые мне пришлось наступить. Мы можем не надеяться на исправление этих багов, их надо просто знать и учитывать их в своём софте. Всех, кто тоже имеет подобную инфу, прошу поделиться ею здесь. ----- PGP key  |
|
|
Создано: 23 июля 2009 18:33 · Личное сообщение · #2 Баг номер раз Баг в документации к функции PsGetProcessExitTime в ядре Windows Функция PsGetProcessExitTime находится в выгружаемой секции PAGE, а значит её можно вызывать только на IRQL <= APC_LEVEL. Теперь смотрим, что по этому поводу написано в MSDN: msdn.microsoft.com/en-us/library/ms796686.aspx Requirements IRQL: <=DISPATCH_LEVEL Зарегистрированы реальные случаи падения драйвера из-за вызова этой функции на DISPATCH_LEVEL, так что знайте, что документации верить нельзя ----- PGP key |
|
|
Создано: 24 июля 2009 09:47 · Личное сообщение · #3 Баг номер два Это баг в ядре Windows 7 x86 (ntkrpamp.exe 6.1.7600.16385) Суть бага в том, что обработчик IRP_MJ_READ для девайса диска может вызываться на DISPATCH_LEVEL. Читаем MSDN: msdn.microsoft.com/en-us/library/ms795194.aspx msdn.microsoft.com/en-us/library/ms794997.aspx Requirements IRQL: PASSIVE_LEVEL (see Comments section) The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of lowest-level device drivers, and of intermediate drivers layered above them in the system paging path, can be called at IRQL = APC_LEVEL and in an arbitrary thread context. Т.е. судя по документации, DispatchRead может вызываться на IRQL <= APC_LEVEL. На этот раз баг в ядре, а не в документации, поскольку такое поведение замечено исключительно на Windows 7. ----- PGP key |
|
|
Создано: 24 июля 2009 17:25 · Личное сообщение · #4 Баг номер три Драйвер кардридера Richon 1394 OHCI Compliant Host Controller от Microsoft для Windows 7 x86 не обрабатывает IOCTL_SCSI_GET_CAPABILITIES и возвращает 0 в поле MaximumTransferLength для вызова IOCTL_STORAGE_QUERY_PROPERTY с параметром StorageAdapterProperty. Таким образом мы не можем узнать MaximumTransferLength этого адаптера. В таких случаях используйте максимальный размер блока 32кб, это плохо для производительности, но поддерживается всем железом. ----- PGP key |
|
|
Создано: 24 июля 2009 18:01 · Поправил: Jupiter · Личное сообщение · #5 ntldr пишет: Richon 1394 OHCI Compliant Host Controller у меня такой на ноуте как раз %) есть ли метод косвенно выяснить MaximumTransferLength ? кста, правильное название: Ricoh ----- EnJoy! |
|
|
Создано: 24 июля 2009 19:07 · Личное сообщение · #6 IOCTL не работает, так что остается либо пробовать читать с разными размерами блока до тех пор, пока не возникнет ошибка, либо искать структуру PORT_CONFIGURATION_INFORMATION от драйвера SCSI порта адаптера. И то и другое - не безопасно и не универсально, мне приходилось встречать устройства, которые намертво зависают при попытке прочитать больше MaximumTransferLength. ИМХО единственный приемлемый вариант - использовать безопасный размер в 32кб, как делает в таком случае драйвер файловой системы. ----- PGP key |
|
|
Создано: 06 октября 2009 17:51 · Личное сообщение · #7 Компилятор Это не совсем баг, но грабли, на которые можно наступить. Visual C++ 2008 не генерирует релоки для x64 DLL, если DLL состоит только из нашего кода (скомпилирована с /NODEFAULTLIB и /ENTRY) и не содержит явно заданных указателей в секции данных. На эти грабли можно наступить создавая драйвер в VC2008. Code:
Если скомпилировать вышеприведенный драйвер под x64, то он получится без релоков, и будет запускаться только если его ImageBase не занят, что делает эти грабли коварными и трудноуловимыми. Эта особенность компилятора связана с тем, что строка "Hello World" адресуется lea rcx, "Hello World\n", относительно rip. VC2008 любит вставлять базонезависимую адресацию вместо релоков, поэтому даже достаточно сложный драйвер может не иметь релоков. Чтобы убрать эти грабли достаточно вставить в свободное место строку "char *test = "test";", которая заставит создать релокацию в секции данных. ----- PGP key |
|
|
Создано: 11 сентября 2010 01:58 · Личное сообщение · #8 ntldr даже /FIXED:NO не помогает? ----- EnJoy! |
|
|
Создано: 22 сентября 2010 21:23 · Личное сообщение · #9 Наиболее острые грабли это выравнивание стека - если сделать к примеру push ax.. SEH_Prolog.. #XCPT, то сех вызван не будет. Посему критический рантайм должен самостоятельно выравнивать стек. |
|
|
Создано: 23 сентября 2010 14:07 · Поправил: DenCoder · Личное сообщение · #10 В MS Visual Studio 2008 Pro (Version 9.0.21022.8 RTM) в среде Visual C++ обнаружил сегодня такие 3 бага: 1) Если определить структуру локально в функции, Intellisense не работает на объектах этой структуры. Впервые так сегодня поступил и понял, что это неудобно, лучше объявлять как раньше, в заголовках; 2) Связана с 1-ой видимо. При большой степени вложенности блока (8-10), и в каждом блоке (на каждом уровне вложенности) объвлены свои переменные и объекты, отладчик не показывает члены некоторых объектов структур, объявленных в этом блоке. В watch при попытке преобразовать к типу пишет Error: bad type cast, в столбце Type выводит что-то вроде этого CSomeClassDlg::FindTcxTables::__l6::LIST *. В блоках меньшей степени вложенности (2-3) такой ошибки нет; 3) Неправильно вычисляются отладчиком длинные выражения с указателями и преобразованиями к типам, хотя выполняется все правильно, как и задумано. ----- IZ.RU |
|
|
Создано: 23 сентября 2010 17:48 · Личное сообщение · #11 Прочитай ещё раз внимательно шапку и пиши по теме. |
|
|
Создано: 31 января 2011 07:39 · Личное сообщение · #12 Куча багов в secur32.dll версии 5.1.2600.5753. Семейство багов с возможным выпадением любого процесса в ACCESS VIOLATION (и теоретически может быть использовано для удаленного захвата системы) связано с парсингом ключа реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders. В какой-то части кода поскупились нулик добавить для юникода... Семейство багов носит непостоянный характер. Пытался отловить, но создать такие условия при которых появляется хотя бы один из них, пока не получилось. Дамп в момент бага дает не так много информации... Спасибо "обновлению" KB959426 :D... Баг в Adobe Flash Player 10.0.22.85. Замечен только на одной флеш-игре на vkontakte.ru, на других не проверял, но к ютубе, например это не относится. Суть - медленно, но верно, у плеера от адобы жутко увеличивается аппетит. У меня за сутки "нужный" ему объем вырастает с 400 мб до 1,7 Гигов. В 10.1 за полсуток такого бага не заметил. Так что, внимание, любители флешек!!! Есть и 10.2, но она бета. Не советую использовать серьезно, но можно помочь адобе... :D P.S. Всем привет! С возвращением меня! :D ----- IZ.RU |
|
|
Создано: 14 февраля 2011 15:03 · Личное сообщение · #13 Флеш плеер всю жизнь себя так ведет, еще с 9 версии. Хз от чего это зависит, проявляется крайне редко, но проявившись может многократно повторяться. ----- Yann Tiersen best and do not fuck |
|
|
Создано: 23 февраля 2011 14:39 · Личное сообщение · #14 Ну иногда про баги можно почитать у ----- Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли. |
|
|
Создано: 03 апреля 2011 20:34 · Личное сообщение · #15 Как ни странно, но проблема с "парсингом ключа реестра" (дело оказалось не в парсинге, а в немного кривой реализации Nt!NtQueryValueKey) решается, если в конце ключа поставить, например, пробел.  http://answers.microsoft.com/ru-ru/windows/forum/windows_xp-system/secur32dll/f89b304a-a251-e011-8dfc-68b599b31bf5 ----- IZ.RU |
|
|
Создано: 10 ноября 2011 19:57 · Поправил: GgeorgeS · Личное сообщение · #16 Во у меня такой фрагмент кода, расчитанный на Windows и Linux: #if defined WIN64 #define _WIN32_WINNT 0x0400 #include <windows.h> #else #include <unistd.h> #endif При трансляции под виндами получаю катастрофическую ошибку: невозможно открыть файл unistd.h. Но ведь в виндах ветка кода, содержащая #include <unistd.h>, должна обходиться. Может чего в окружении не так? |
|
|
Создано: 10 ноября 2011 20:17 · Личное сообщение · #17 Во-первых, под какую винду идёт сборка? Во-вторых, возьми и дефайны все посмотри. В-третьих, непонятно, что вообще пост делает в этом топике. |
|
|
Создано: 10 ноября 2011 20:40 · Поправил: GgeorgeS · Личное сообщение · #18 Archer пишет: Во-первых, под какую винду идёт сборка? x64 Archer пишет: Во-вторых, возьми и дефайны все посмотри. unistd.h - это линуксовое, но под виндой вроде эта ветка должна пропускаться Archer пишет: В-третьих, непонятно, что вообще пост делает в этом топике. Я подумал, что это из-за окружения ошибка. Не подскажите тогда, куда это подсунуть можно? |
|
|
Создано: 10 ноября 2011 22:09 · Личное сообщение · #19 В х64 винде оно с подчёркиванием должно быть, линк http://sourceforge.net/apps/mediawiki/predef/title=Operating_Systems Посмотреть дефайны-это поглядеть, какие вещи отдефайнены на данный момент в целях отладки. От компиля зависит, в студии можно в проекте прям поглядеть. Лучше в отдельный топик в программировании, ибо сюда постятся явные ошибки в ОС/документации, а не косяки юзера, источник которых неизвестен. |
|
|
Создано: 10 ноября 2011 22:27 · Личное сообщение · #20 Archer пишет: В х64 винде оно с подчёркиванием должно быть ... Спасибо!!! |
|
eXeL@B —› Дневники и блоги —› Баги в операционных системах и окружении |
Для печати