Помогите найти причину BSOD'а!

Наткнулся на статью "Процедура DriverEntry и предварительные объявления–часть 14" с сайта compkniga.com. В ней есть пример простого драйвера "в стиле NT". Чтобы было интересней читать, решил сразу перевести сишный код на асм. Вот процедура DriverEntry:

Код (Text):

1. DriverEntry proc pDriverObject:DWORD, pusRegistryPath:DWORD
2. local pFDO:DWORD
3.  
4. mov eax, pDriverObject
5. assume eax:ptr DRIVER_OBJECT
6. mov [eax].MajorFunction[IRP_MJ_CREATE*4], offset Create_File_IRPprocessing
7. mov [eax].MajorFunction[IRP_MJ_CLOSE*4], offset CloseHandle_IRPprocessing
8. mov [eax].MajorFunction[IRP_MJ_READ*4], offset ReadWrite_IRPhandler
9. mov [eax].MajorFunction[IRP_MJ_WRITE*4], offset ReadWrite_IRPhandler
10. mov [eax].MajorFunction[IRP_MJ_DEVICE_CONTROL*4], offset DeviceControlRoutine
11. mov [eax].DriverUnload, offset UnloadRoutine
12.  
13. invoke RtlInitUnicodeString, addr usDeviceName, addr uszDeviceName
14. invoke RtlInitUnicodeString, addr usSymbolicLinkName, addr uszSymbolicLinkName
15.  
16. invoke IoCreateDevice, pDriverObject, sizeof EXAMPLE_DEVICE_EXTENSION, addr usDeviceName, \
17.                        FILE_DEVICE_UNKNOWN, 0, FALSE, addr pFDO
18.  
19. .if eax != STATUS_SUCCESS
20.     ret
21. .endif
22.  
23. lea eax, DevExt
24. assume eax:ptr EXAMPLE_DEVICE_EXTENSION
25. push pFDO
26. pop [eax].pFDO
27.  
28.  
29.  
30. lea eax, pFDO
31. invoke DbgPrint, addr exdbg3, eax
32.  
33. ;lea eax, DevExt
34. invoke DbgPrint, addr exdbg33, eax
35.  
36. invoke IoCreateSymbolicLink, addr usSymbolicLinkName, addr usDeviceName
37.  
38. .if eax != STATUS_SUCCESS
39.     push eax
40.     invoke IoDeleteDevice, pFDO
41.     pop eax
42.     ret
43. .endif
44.  
45. mov eax, STATUS_SUCCESS
46. ret
47. DriverEntry endp

В этой процедуре закомментирована строчка
lea ebx, DevExt
Если ее разкомментировать, то драйвер вылетает в BSOD с ошибкой 00000050
Извиняюсь, не 00000050, а 0000007е (типа необрабатываемое исключение, или что-то подобное)
Не могу понять, почему...Немного выше указанной строк стоит такая же lea.

 

Во-первых, там закомментирована lea eax, DevExt.
Во-вторых, а что вообще такое DevExt, где оно объявлено?
В-третьих, выложи анализ дампа падения, !analyze -v в WinDbg.

 

1. Да, все верно, lea eax, DevExt.
2. DevExt это структура для хранения указателя на FDO и символьной ссылки:

EXAMPLE_DEVICE_EXTENSION STRUCT

pFDO DWORD ?
usSymLinkName UNICODE_STRING <>

EXAMPLE_DEVICE_EXTENSION ENDS

объявленна в сегменте данных .data

3. Анализ дампа в прикрепленном файле.

 

Что это?!
Выложи нормальный .dmp-файл.

 

Ничего не понимаю: запускал сейчас тот же пример, чтобы получить аварийный дамп, и драйвер работал нормально. Никаких вылетов. Даже не знаю, что это могло быть. Прошу прощение за напрасное беспокойство.

 

Виртуальная машина какая?

 

Что имеется в виду под виртуальной машиной (извини, я еще совсем нуб)?

 

Foo
Как вы объявляете DevExt ? и как присваеваете её значения ? это случаем не указатель?

 

DevExt это структура для хранения указателя на FDO и символьной ссылки:

EXAMPLE_DEVICE_EXTENSION STRUCT

pFDO DWORD ?
usSymLinkName UNICODE_STRING <>

EXAMPLE_DEVICE_EXTENSION ENDS

объявленна в сегменте данных .data так:
DevExt EXAMPLE_DEVICE_EXTENSION <>

Присвоение значения:

lea eax, DevExt
assume eax:ptr EXAMPLE_DEVICE_EXTENSION
push pFDO
pop [eax].pFDO

 

Я конкретно ступил с DevExt, разместив ее в .data секции. Ведь это должна была быть структура DEVICE_EXTENSION, место под которую отводится при вызове IoCreateDevice. FDO -> DeviceExtension и содержит нужный указатель. Его и надо было использовать. Да... каюсь.

 

Тту появился новый гемор:

Код (Text):

1. Create_File_IRPprocessing proc pDeviceObject:DWORD, pIrp:DWORD
2. local pStack:DWORD
3.  
4. mov eax, pIrp
5. assume eax:ptr _IRP
6. mov eax, [eax].Tail.Overlay.CurrentStackLocation
7. mov pStack, eax
8.  
9. assume eax:ptr IO_STACK_LOCATION
10. mov eax, dword ptr [eax].FileObject
11. assume eax:ptr FILE_OBJECT
12. ;movzx ebx, [eax].FileName._Length
13.  
14. invoke DbgPrint, addr exdbg66, eax
15.  
16. invoke CompleteIrp, pIrp, STATUS_SUCCESS, 0
17. ret
18. Create_File_IRPprocessing endp

В этой процедуре, которая должна обрабатывать IRP_MJ_CREATE, закомментированная строка вызывает BSOD с такими данными:
STOP: 0x0000008e (0xc0000005, ...)
Это исключение GP?

 

VirtualBox
Windows Virtual PC
VMware Workstation
Parallels Desktop/Workstation
И т.д.

Я к тому спросил, что некоторые виртуалки весьма глючные сами по себе (например, Parallels Desktop), они могут ронять виртуалку на ровном месте примерно с такими же кодами, как у тебя (0x50, 0x7e, ...). А у тебя здесь да, проблема с device extension, его нужно брать по адресу pDevObj -> DeviceExtension после успешного вызова IoCreateDevice().

 

Никаких WM у меня не запущено. Ошибку с DeviceExtension я исправил, все работает, но, как я уже писал, образовалась новая проблемка (см. мой предыдущий пост). Не мог бы ты и сней помочь?

Насчет дампов WinDbg: дамп ядра на моей машине весит 104 МБ. Точно нужно его выкладывать, или можно просто скопировать вывод WinDbg?

 

Может, стоит всё таки взять C для начала? И примеры на C смотреть тоже. Часть ошибок удастся избежать автоматически. Асм нужно брать тогда, когда пишешь какие-то аппаратно-зависимые вещи или что-то, что следует сильно оптимизировать по скорости, ну например, загрузчик операционной системы, алгоритмы шифрования и т.д.

Однако, на реальной машине, что ли, запускаешь? Угробишь же систему.

На первый взгляд в коде всё правильно.

Сначала вывод давай, если будет не достаточно, тебе скажут об этом.

 

Вот - выкладываю вывод WinDbg:

Код (Text):

1. Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
2. Copyright (c) Microsoft Corporation. All rights reserved.
3.  
4.  
5. Loading Dump File [C:\WINDOWS\MEMORY.DMP]
6. Kernel Summary Dump File: Only kernel address space is available
7.  
8. Symbol search path is: C:\WINDOWS\symbols;srv*c:\Symbols*http://msdl.microsoft.com/download/symbols
9. Executable search path is:
10. Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
11. Product: WinNt, suite: TerminalServer SingleUserTS
12. Built by: 2600.xpsp_sp3_qfe.080423-1303
13. Machine Name:
14. Kernel base = 0x804d7000 PsLoadedModuleList = 0x805634c0
15. Debug session time: Thu Feb 23 18:54:48.562 2012 (GMT+3)
16. System Uptime: 0 days 0:00:58.234
17. Loading Kernel Symbols
18. ...............................................................
19. .............................................................
20. Loading User Symbols
21. PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details
22. Loading unloaded module list
23. ............
24. *******************************************************************************
25. *                                                                             *
26. *                        Bugcheck Analysis                                    *
27. *                                                                             *
28. *******************************************************************************
29.  
30. Use !analyze -v to get detailed debugging information.
31.  
32. BugCheck 8E, {c0000005, 8057bc2a, b337ba00, 0}
33.  
34. PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details
35. PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details
36. Probably caused by : ntkrnlmp.exe ( nt!IopParseDevice+a69 )
37.  
38. Followup: MachineOwner
39. ---------
40.  
41. 0: kd> !analyze -v
42. *******************************************************************************
43. *                                                                             *
44. *                        Bugcheck Analysis                                    *
45. *                                                                             *
46. *******************************************************************************
47.  
48. KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
49. This is a very common bugcheck.  Usually the exception address pinpoints
50. the driver/function that caused the problem.  Always note this address
51. as well as the link date of the driver/image that contains this address.
52. Some common problems are exception code 0x80000003.  This means a hard
53. coded breakpoint or assertion was hit, but this system was booted
54. /NODEBUG.  This is not supposed to happen as developers should never have
55. hardcoded breakpoints in retail code, but ...
56. If this happens, make sure a debugger gets connected, and the
57. system is booted /DEBUG.  This will let us see why this breakpoint is
58. happening.
59. Arguments:
60. Arg1: c0000005, The exception code that was not handled
61. Arg2: 8057bc2a, The address that the exception occurred at
62. Arg3: b337ba00, Trap Frame
63. Arg4: 00000000
64.  
65. Debugging Details:
66. ------------------
67.  
68. PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details
69. PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details
70.  
71. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - <Unable to get error code text>
72.  
73. FAULTING_IP:
74. nt!IopParseDevice+a69
75. 8057bc2a c7436001000000  mov     dword ptr [ebx+60h],1
76.  
77. TRAP_FRAME:  b337ba00 -- (.trap 0xffffffffb337ba00)
78. ErrCode = 00000002
79. eax=00000000 ebx=00000000 ecx=00000000 edx=00000001 esi=88953490 edi=889534a0
80. eip=8057bc2a esp=b337ba74 ebp=b337bb4c iopl=0         nv up ei pl zr ac pe nc
81. cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010256
82. nt!IopParseDevice+0xa69:
83. 8057bc2a c7436001000000  mov     dword ptr [ebx+60h],1 ds:0023:00000060=????????
84. Resetting default scope
85.  
86. DEFAULT_BUCKET_ID:  DRIVER_FAULT
87.  
88. BUGCHECK_STR:  0x8E
89.  
90. PROCESS_NAME:  example.exe
91.  
92. LAST_CONTROL_TRANSFER:  from 805221f9 to 8053767a
93.  
94. STACK_TEXT:  
95. b337b5c8 805221f9 0000008e c0000005 8057bc2a nt!KeBugCheckEx+0x1b
96. b337b990 804de403 b337b9ac 00000000 b337ba00 nt!KiDispatchException+0x3b1
97. b337b9f8 804de3b4 b337bb4c 8057bc2a badb0d00 nt!CommonDispatchException+0x4d
98. b337ba14 8056d5b4 b337bb3c 889534a0 88ab7240 nt!KiExceptionExit+0x18a
99. b337bb4c 8056d03b 88f17f08 00000000 8895ce58 nt!ObCreateObject+0x12a
100. b337bbc4 80570402 00000000 b337bc04 00000040 nt!ObpLookupObjectName+0x53c
101. b337bc18 8057c24e 00000000 00000000 37bc8401 nt!ObOpenObjectByName+0xea
102. b337bc94 8057c31d 0012ff70 c0100080 0012ff10 nt!IopCreateFile+0x407
103. b337bcf0 8057c360 0012ff70 c0100080 0012ff10 nt!IoCreateFile+0x8e
104. b337bd30 804dd99f 0012ff70 c0100080 0012ff10 nt!NtCreateFile+0x30
105. b337bd30 7c90e4f4 0012ff70 c0100080 0012ff10 nt!KiFastCallEntry+0xfc
106. WARNING: Frame IP not in any known module. Following frames may be wrong.
107. 0012ff68 00000000 00000000 00000000 00000000 0x7c90e4f4
108.  
109.  
110. STACK_COMMAND:  kb
111.  
112. FOLLOWUP_IP:
113. nt!IopParseDevice+a69
114. 8057bc2a c7436001000000  mov     dword ptr [ebx+60h],1
115.  
116. SYMBOL_STACK_INDEX:  0
117.  
118. SYMBOL_NAME:  nt!IopParseDevice+a69
119.  
120. FOLLOWUP_NAME:  MachineOwner
121.  
122. MODULE_NAME: nt
123.  
124. IMAGE_NAME:  ntkrnlmp.exe
125.  
126. DEBUG_FLR_IMAGE_TIMESTAMP:  480f21b7
127.  
128. FAILURE_BUCKET_ID:  0x8E_nt!IopParseDevice+a69
129.  
130. BUCKET_ID:  0x8E_nt!IopParseDevice+a69
131.  
132. Followup: MachineOwner
133. ---------

 

Однозначного ответа этот вывод, к сожалению, не даёт. Ясно пока только одно: падение произошло уже после того, как твой драйвер завершил Create-запрос. Покажи код своей функции CompleteIrp(). Что за драйвер-то вообще? Он что-нибудь делает полезного? Например, аттачится ли он в стек какого-нибудь девайса или ещё что-нибудь в этом роде? Строчка movzx ebx, [eax].FileName._Length (тут только _Length меня смущает, зачем подчёркивание?) сама по себе не может приводить к сбою, т.к. eax инициализирован правильно, а поле FileObject в структуре IO_STACK_LOCATION не может быть NULL в случае Create-запроса.

 

Функция CompleteIrp:

Код (Text):

1. CompleteIrp proc pIRP:DWORD, ntStatus:DWORD, Info:DWORD
2.  
3. mov eax, pIRP
4. assume eax:ptr _IRP
5. push ntStatus
6. pop [eax].IoStatus.Status
7. push Info
8. pop [eax].IoStatus.Information
9.  
10. mov ecx, pIRP
11. mov edx, IO_NO_INCREMENT
12. call IofCompleteRequest
13.  
14. mov eax, ntStatus
15. ret
16. CompleteIrp endp

Драйвер не делает ничего, написан в учебных целях, только запускается и выводит отладочные сообщения из зарегистрированных процедур. Это пример из одной статьи про драйвера в стиле NT, просто там он на C, а я решил его в асм перевести, и вот...
На всякий случай прикрепляю код драйвера.

Подчеркивание в _Length - это я использую inc файлы из kmd от Four-F (есть на wasm.ru его статья про драйвера режима ядра).

 

код драйвера.
Что-то файл не прикрепляется, или я чего-то не того...

вто он

Код (Text):

1. ;goto make
2.  
3. .586
4. .model flat, stdcall
5. option casemap:none
6.  
7. IOCTL_9 equ 22E000h
8.  
9. include c:\masm32\include\w2k\ntstatus.inc
10. include c:\masm32\include\w2k\ntoskrnl.inc
11. include c:\masm32\include\w2k\ntddk.inc
12. include c:\masm32\include\w2k\hal.inc
13. include c:\masm32\include\w2k\native.inc
14.  
15. includelib c:\masm32\lib\w2k\hal.lib
16. includelib c:\masm32\lib\w2k\ntoskrnl.lib
17.  
18. EXAMPLE_DEVICE_EXTENSION STRUCT
19.  
20.    pFDO DWORD ?
21.    usSymLinkName UNICODE_STRING <>
22.  
23. EXAMPLE_DEVICE_EXTENSION ENDS
24.  
25. .data
26.  
27. MySpinLock KSPIN_LOCK ?
28.  
29. dbg1 db "Module ex1.sys : DriverEntry", 0
30. dbg2 db "Module ex1.sys : CreateClose", 0
31. dbg3 db "Module ex1.sys : DriverUnload", 0
32. dbg4 db "Module ex1.sys : DispatchIoControl", 0
33.  
34. dbg6 db "Module ex1.sys : AddDevice", 0
35.  
36. exdbg1 db "=Example= In DriverEntry.", 0
37. exdbg2 db "=Example= RegistryPath = %ws", 0
38. exdbg3 db "=Example= FDO %08X", 0
39. exdbg33 db "DevExt = %08X.", 0
40. exdbg4 db "=Example= DriverEntry successfully completed.", 0
41. exdbg5 db "-Example- in ReadWrite_IRPhandler.", 0
42. exdbg6 db "-Example- Create File is %ws", 0
43. exdbg66 db "-Example- File Object Pointer %08X", 0
44. exdbg7 db "-Example- In Close handler.", 0
45.  
46. uszDeviceName dw "\", "D", "e", "v", "i", "c", "e", "\", "e", "x", "1", 0
47. uszSymbolicLinkName dw "\", "G", "L", "O", "B", "A", "L", "?", "?", "\", "e", "x", "1", 0
48. usDeviceName UNICODE_STRING <>
49. usSymbolicLinkName UNICODE_STRING <>
50. szTargetModuleName db "user32.dll", 0
51. szTargetProcName db "MessageBoxA", 0
52.  
53. .code
54.  
55. CompleteIrp proc pIRP:DWORD, ntStatus:DWORD, Info:DWORD
56.  
57. mov eax, pIRP
58. assume eax:ptr _IRP
59. push ntStatus
60. pop [eax].IoStatus.Status
61. push Info
62. pop [eax].IoStatus.Information
63.  
64. mov ecx, pIRP
65. mov edx, IO_NO_INCREMENT
66. call IofCompleteRequest
67.  
68. mov eax, ntStatus
69. ret
70. CompleteIrp endp
71.  
72. UnloadRoutine proc pDriverObject:DWORD
73.  
74. invoke IoDeleteSymbolicLink, offset usSymbolicLinkName
75. mov eax, pDriverObject
76. invoke IoDeleteDevice, (DRIVER_OBJECT PTR [eax]).DeviceObject
77.  
78. ret
79. UnloadRoutine endp
80.  
81. DeviceControlRoutine proc pDeviceObject:DWORD, pIrp:DWORD
82. local status:NTSTATUS
83. local Bytes:DWORD
84. local irql:DWORD
85. local CurrentIrql:DWORD
86.  
87. mov esi, pIrp
88. assume esi:ptr _IRP
89. mov edi, [esi].Tail.Overlay.CurrentStackLocation
90. assume edi:ptr IO_STACK_LOCATION
91.  
92. .if [edi].Parameters.DeviceIoControl.IoControlCode
93.  
94. .endif
95.  
96. invoke CompleteIrp, pIrp, STATUS_SUCCESS, 0
97. ret
98. DeviceControlRoutine endp
99.  
100. CloseHandle_IRPprocessing proc pDeviceObject:DWORD, pIrp:DWORD
101.  
102. ;invoke DbgPrint, addr exdbg7
103.  
104. invoke CompleteIrp, pIrp, STATUS_SUCCESS, 0
105. ret
106. CloseHandle_IRPprocessing endp
107.  
108. Create_File_IRPprocessing proc pDeviceObject:DWORD, pIrp:DWORD
109. local pStack:DWORD
110.  
111. mov eax, pIrp
112. assume eax:ptr _IRP
113. mov eax, [eax].Tail.Overlay.CurrentStackLocation
114. mov pStack, eax
115.  
116. assume eax:ptr IO_STACK_LOCATION
117. mov eax, dword ptr [eax].FileObject
118. assume eax:ptr FILE_OBJECT
119. movzx ebx, [eax].FileName._Length
120.  
121. ;assume ebx:ptr UNICODE_STRING
122. ;mov eax, [ebx].Buffer
123. invoke DbgPrint, addr exdbg66, eax
124.  
125. invoke CompleteIrp, pIrp, STATUS_SUCCESS, 0
126. ret
127. Create_File_IRPprocessing endp
128.  
129. ReadWrite_IRPhandler proc pDeviceObject:DWORD, pIRP:DWORD
130. local status:NTSTATUS
131. local Bytes:DWORD
132.  
133. mov status, STATUS_SUCCESS
134.  
135. invoke DbgPrint, addr exdbg5
136.  
137. invoke CompleteIrp, pIRP, status, Bytes
138. ret
139. ReadWrite_IRPhandler endp
140.  
141. .code INIT
142.  
143. DriverEntry proc pDriverObject:DWORD, pusRegistryPath:DWORD
144. local pFDO:DWORD  
145. local devex:DWORD
146.  
147. invoke DbgPrint, addr exdbg1
148. mov eax, pusRegistryPath
149. assume eax:ptr UNICODE_STRING
150. invoke DbgPrint, addr exdbg2, [eax].Buffer
151.  
152. mov eax, pDriverObject
153. assume eax:ptr DRIVER_OBJECT
154. mov [eax].MajorFunction[IRP_MJ_CREATE*4], offset Create_File_IRPprocessing
155. mov [eax].MajorFunction[IRP_MJ_CLOSE*4], offset CloseHandle_IRPprocessing
156. mov [eax].MajorFunction[IRP_MJ_READ*4], offset ReadWrite_IRPhandler
157. mov [eax].MajorFunction[IRP_MJ_WRITE*4], offset ReadWrite_IRPhandler
158. mov [eax].MajorFunction[IRP_MJ_DEVICE_CONTROL*4], offset DeviceControlRoutine
159. mov [eax].DriverUnload, offset UnloadRoutine
160.  
161. invoke RtlInitUnicodeString, addr usDeviceName, addr uszDeviceName
162. invoke RtlInitUnicodeString, addr usSymbolicLinkName, addr uszSymbolicLinkName
163.  
164. invoke IoCreateDevice, pDriverObject, sizeof EXAMPLE_DEVICE_EXTENSION, addr usDeviceName, \
165.                        FILE_DEVICE_UNKNOWN, 0, FALSE, addr pFDO
166.  
167. .if eax != STATUS_SUCCESS
168.     ret
169. .endif
170.  
171. mov eax, pFDO
172. assume eax:ptr DEVICE_OBJECT
173. push [eax].DeviceExtension
174. pop devex
175.  
176. lea eax, devex
177. assume eax:ptr EXAMPLE_DEVICE_EXTENSION
178. push pFDO
179. pop [eax].pFDO
180.  
181.  
182.  
183. lea eax, devex
184. invoke DbgPrint, addr exdbg3, eax
185.  
186. lea eax, pFDO
187. invoke DbgPrint, addr exdbg33, eax
188.  
189. invoke IoCreateSymbolicLink, addr usSymbolicLinkName, addr usDeviceName
190.  
191. .if eax != STATUS_SUCCESS
192.     push eax
193.     invoke IoDeleteDevice, pFDO
194.     pop eax
195.     ret
196. .endif
197.  
198.  
199. mov eax, STATUS_SUCCESS
200. ret
201. DriverEntry endp
202.  
203. end DriverEntry
204.  
205. :make
206. set drv=ex1
207. c:\masm32\bin\ml /c /coff /nologo %drv%.bat
208. c:\masm32\bin\link /nologo /driver /align:32 /base:0x10000 /subsystem:native /ignore:4078 /out:%drv%.sys %drv%.obj
209. del %drv%.obj
210. pause

 

Подозреваю, что ф-ия обработки IRP_MJ_CREATE портит ebx, что сильно не нравится вызывающей ее ф-ии. Если попробовать использовать 'movzx ecx, [eax].FileName._Length', BSoD остается? Ну и ebx вообще не трогать, либо сохранять его значение перед использованием и восстанавливать перед выходом из ф-ии?

P.S. Писать драйвера на ассемблере без использования VM или второго компьютера для отладки, скажем мягко -- усложнение и без того непростой задачи.

 

Foo
А почему аргументы для IofCompleteRequest() передаются через регистры у тебя? Соглашение fastcall только на x86-64 используется. Почему не через invoke, как обычно, вызываешь? И почему в полном исходнике этот вызов уже переделан на invoke? Что-то ты химией какой-то дерзновенной занимаешься. Регистры, которые используешь в функции, необходимо сохранять перед использованием и восстанавливать при выходе, о чём выше тебе написали. Может, лучше C всё таки, а?