Трабла с строкой. Несколько мистического плана...

Следующая часть кода, по идее должна "нажать" и через 1 сек. "отжать" кнопку спикерфона на системном телефоне. Делается это довольно примитивно - посылая строку через функцию lineDevSpecific. Но, как выяснилось, проблема не связана с TAPI.

Код (Text):

1. .00401199: 6A0B             push        00B           ; длина строки ниже
2. .0040119B: 6867304000    push        000403067 ; ptr to asciiz - "PUSH_BTN/N"
3. .004011A0: 6A00             push        000
4. .004011A2: 6A00             push        000
5. .004011A4: 53                 push        ebx          ; хэндл линии
6. .004011A5: E80C070000    call        lineDevSpecific
7. .004011AA: 68E8030000    push        0000003E8
8. .004011AF: E8AE060000    call        Sleep         ; ждем 1 сек.
9. .004011B4: 6A0B              push        00B
10. .004011B6: 6867304000     push        000403067  ; "PUSH_BTN/N"
11. .004011BB: 6A00              push        000
12. .004011BD: 6A00              push        000
13. .004011BF: 53                  push        ebx
14. .004011C0: E8F1060000     call        lineDevSpecific

Первый вызов отрабатывает ок, а второй возращает ошибку. Запустив это дело под API монитором (а затем и под дебаггером) я офигел - вместо строки "PUSH_BTN/N", во втором вызове от строки остается только хвост - "/N"! Люди добрые, объясните как такое может быть? Во время выполнения Sleep - строку кто то покоцал.. Кривой TSP драйвер?
Лог SoftSnoop-а:

Код (Text):

1. 1-й вызов:
2. API: lineDevSpecific(tapi32.dll), 00010367h, 00000000h, 00000000h, 00403067h="PUSH_BTN/N", 0000000Bh
3. API: lineDevSpecific returned: 00010323h
4. 2-й вызов:
5. API: lineDevSpecific(tapi32.dll), 00010367h, 00000000h, 00000000h, 00403067h="/N", 0000000Bh
6. API: lineDevSpecific returned: 00010312h

Доп. инфа к размышлению:
1. В программе есть еще один треад обрабатывающий всякие тапишные эвенты. Эту строку он вообще никоим образом не трогает.
2. Кусок кода выше выполняется при создании окна (WM_CREATE)

 

А куда ведёт "ptr to asciiz" - не в стек ли случаем?

 

.data

 

Y_Mur

указатель вида 000403067 обычно на стек не указывает
у стека совсем другие адреса, при старте программы они вида 0012FFxx

 

а lineDevSpecific ничего не должна записать в буфер строки?

 

Не должна по-идее - там поинтер на команду девайсу.

Проясняется помаленьку: Строку грохает lineDevSpecificPostProcess вызываемый из lineDevSpecific.
Вот кусок который соб-но и пишет в мои данные (какого-то хрена):

Код (Text):

1. .text:76EB30DD                 mov     ecx, ebx
2. .text:76EB30DF                 mov     eax, ecx
3. .text:76EB30E1                 add     esi, 28h  
4. .text:76EB30E4                 shr     ecx, 2
5. .text:76EB30E7                 rep movsd           ; В esi указатель на "/N", в edi ptr "PUSH_BTN/N" в моем .data

Но опять же непонятно - после возврата из этой функции строка, если верить дебаггеру и своим глазам, цела. Портится она во время исполнения ф-ции Sleep. (Вот так вот, подло, во сне ;o)

 

movsd не портит строку, если на нее не указывает edi. Поставь бряк на запись в память на это строку (в олли) и посмотри, кто ее затирает.

 

Да, забыл добавить в коде выше edi=00403067h т.е. как раз моя строка.

 

ну тогда создай локальную переменную, копируй туда строку и передавай функциям указатель на эту локальную переменную. Тока ж перед вызовом функций обязательно копируй строку в эту переменную заново!

 

Так и сделал. Даже работает. Но это не есть карашо - у меня тысча таких вот строк...

 

ну и шо? Если функция так устроена, что очищает строку, шо ты будешь делать? Писать свою функцию??? Не надо же для каждой строки создавать отдельную локальную переменную. Создай одну единственную и перед вызовом функции копируй в нее нужную строку. По-другому никак :-/

 

Всё равно есть ощущение, что кто-то хреново парсит строку. "..BTN/N" - достаточно каверзное окончание... Вопрос (уже риторический) кто? m$ tapi? Или разрабы TSP драйвера станции? Чтобы выяснить - надо перелопатить кучу враждебного кода. И потом, хоть убей, я не понимаю - нафига переписывать эту несчастную строку???

 

Зачем тебе переписывать или зачем ф-я ее затирает? Возможно, так совпали звезды. А вообще, почитай описание ф-ии. Возможно,она пишет в этот буфер какой-то ответ.

 

Мистики не бывает.
Пользовательская программа не имеет права портить регистры EBX, EDI...
Похоже, что ты на входе не сохраняешь, а на выходе не восстанавливаешь один из этих регистров.

 

Еще как бывает! Только в компьютерах из ниоткуда появляются ошибки и в никуда исчезают файлы. А объем измеряется в метрах и называется весом!

 

вот это правда мистика
можешь выложить кусок работоспособного кода, де такое наблюдается? (а то твой дописывать лениво)

 

Естественно 2-е. Насчет описания - спасибо за совет. Так и есть - невнимательно я читал msdn. Там есть такое маленькое примечание:

Спасибо огромное всем, кого я напрасно побеспокоил из за своей невнимательности...

 

тада не нада
по крайней мере, пока я не куплю себе LG-Nortel ))