Преобразование строки в нижний регистр

Превед фсем! Как мне преобразовать LPWSTR строку в нижний регистр в ядре? Делаю так:

Код (Text):

1. BOOLEAN IsAdded(PObjectList List, LPWSTR CheckedFileName)
2. {  
3.          LPWSTR NoRegister;
4.     PObjectList Item = List;
5.  
6.  
7.     if (!CheckedFileName) return FALSE;
8.  
9.     NoRegister = CheckedFileName;
10.     _wcslwr (NoRegister);   //Без этой строчки работает
11.  
12.  
13.     while (Item)
14.     {
15.  
16.         if (wcsncmp (Item->FileName,NoRegister, wcslen(NoRegister)) == 0)
17.                  //if (wcsncmp (Item->FileName,CheckedFileName, wcslen(CheckedFileName)) == 0) //Так работает
18.  
19.         {
20.             return TRUE;
21.         }
22.        
23.         Item = Item->NextItem;
24.     }
25.  
26.  
27.     return FALSE;  
28.  
29.  
30. }

Или срабатывает исключение, или сразу синий экран валится(

 

Телепаты тут есть? Думаю, нет. Поэтому, велкам ту WinDbg и кидай сюда резалт от !analyze -v
ща сам сорс гляну еще.

UPD: Кстати, ты уверен, что писать по адресу CheckedFileName можно?

 

DoZENT

вместо wcsncmp используй _wcsnicmp

 

DoZENT
Могу предположить, что в стеке по адресу NoRegister у тебя будет не указатель на строку, а указатель на указатель на эту строку.

 

большиство функций работы со строками требуют IRQL == PASSIVE_LEVEL

 

Строка может быть запросто находиться в read-only памяти. Для таких дел лучше компировать её сначала себе, а потом уже приводить к одному регистру.

 

IceStudent
Обрати внимание, что не работает вариант с использованием локальной переменной NoRegister.

 

crypto
Так локален лишь указатель на строку, а я говорил о самой строке.

 

IceStudent

Если используется сам указатель, то работает.

 

Тогда без отладчика неясно.

 

я еще в 1 посте сказал

так что кидайте плиз сюда результаты автоанализа
желательно еще идой выдрать скомпилированное тело этой функции.

 

Код (Text):

1. kd> !analyze -v
2. *******************************************************************************
3. *                                                                             *
4. *                        Bugcheck Analysis                                    *
5. *                                                                             *
6. *******************************************************************************
7.  
8. ATTEMPTED_WRITE_TO_READONLY_MEMORY (be)
9. An attempt was made to write to readonly memory.  The guilty driver is on the
10. stack trace (and is typically the current instruction pointer).
11. When possible, the guilty driver's name (Unicode string) is printed on
12. the bugcheck screen and saved in KiBugCheckDriver.
13. Arguments:
14. Arg1: 8066f15a, Virtual address for the attempted write.
15. Arg2: 0066f121, PTE contents.
16. Arg3: fc8fa5ec, (reserved)
17. Arg4: 0000000b, (reserved)
18.  
19. Debugging Details:
20. ------------------
21.  
22. *** No owner thread found for resource 80551160
23. *** No owner thread found for resource 80551160
24. *** No owner thread found for resource 80551160
25. *** No owner thread found for resource 80551160
26. *** No owner thread found for resource 80551160
27. *** No owner thread found for resource 80551160
28.  
29. DEFAULT_BUCKET_ID:  DRIVER_FAULT
30.  
31. BUGCHECK_STR:  0xBE
32.  
33. PROCESS_NAME:  System
34.  
35. TRAP_FRAME:  fc8fa5ec -- (.trap 0xfffffffffc8fa5ec)
36. ErrCode = 00000003
37. eax=8066f158 ebx=fc9e9492 ecx=8066f15a edx=00000073 esi=fc8fa738 edi=fc8fa6a8
38. eip=8053554d esp=fc8fa660 ebp=fc8fa660 iopl=0         nv up ei pl nz na po nc
39. cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00210202
40. nt!_wcslwr+0x24:
41. 8053554d 668911          mov     word ptr [ecx],dx        ds:0023:8066f15a=0053
42. Resetting default scope
43.  
44. LOCK_ADDRESS:  805511e0 -- (!locks 805511e0)
45.  
46. Resource @ nt!IopDeviceTreeLock (0x805511e0)    Shared 1 owning threads
47.      Threads: 80eaf3c8-01<*>
48. 1 total locks, 1 locks currently held
49.  
50. PNP_TRIAGE:
51.     Lock address  : 0x805511e0
52.     Thread Count  : 1
53.     Thread address: 0x80eaf3c8
54.     Thread wait   : 0x1e64f
55.  
56. LAST_CONTROL_TRANSFER:  from 8051bf07 to 804f8925
57.  
58. STACK_TEXT:  
59. fc8fa574 8051bf07 000000be 8066f15a 0066f121 nt!KeBugCheckEx+0x1b
60. fc8fa5d4 8053f6ec 00000001 8066f15a 00000000 nt!MmAccessFault+0x8e7
61. fc8fa5d4 8053554d 00000001 8066f15a 00000000 nt!KiTrap0E+0xcc
62. fc8fa660 fc9e9335 8066f158 8066f158 00000000 nt!_wcslwr+0x24
63. fc8fa674 fc9e94e9 00000000 8066f158 8066f158 ntts!IsAdded+0x26 [c:\ntts\newf.h @ 92]
64. fc8fa688 8053c808 fc8fa76c 80000000 fc8fa740 ntts!NewNtOpenFile+0x57 [c:\ntts\newf.h @ 203]
65. fc8fa688 804fdb95 fc8fa76c 80000000 fc8fa740 nt!KiFastCallEntry+0xf8
66. fc8fa718 80593049 fc8fa76c 80000000 fc8fa740 nt!ZwOpenFile+0x11
67. fc8fa778 80593243 fc8fa79c fa20b000 00029f00 nt!PiLookupInDDB+0x67
68. fc8fa7a4 8058301e fc8fa88c 80000490 fa20b000 nt!PpCheckInDriverDatabase+0x7f
69. fc8fa81c 80575323 fc8fa88c 80000490 fa20b000 nt!IopPrepareDriverLoading+0x254
70. fc8fa8f4 80583719 80000490 00000000 fc8fa900 nt!IopLoadDriver+0x43f
71. fc8fa938 805dbe7d e18556a8 00000001 80000490 nt!PipCallDriverAddDeviceQueryRoutine+0x235
72. fc8fa984 805dc1b2 fc8faa10 e1855694 fc8fa9e4 nt!RtlpCallQueryRegistryRoutine+0x3b1
73. fc8fa9e8 80584fa1 00000000 00000084 00000001 nt!RtlQueryRegistryValues+0x2a6
74. fc8faabc 8058645e 00000000 00000001 fc8fad54 nt!PipCallDriverAddDevice+0x261
75. fc8fad18 80586914 80e994c8 00000001 00000000 nt!PipProcessDevNodeTree+0x1a4
76. fc8fad4c 804f5573 00000003 80551240 8055a1fc nt!PiProcessReenumeration+0x60
77. fc8fad74 80533dd0 00000000 00000000 80eaf3c8 nt!PipDeviceActionWorker+0x141
78. fc8fadac 805c4a28 00000000 00000000 00000000 nt!ExpWorkerThread+0x100
79. fc8faddc 80540fa2 80533cd0 00000001 00000000 nt!PspSystemThreadStartup+0x34
80. 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
81.  
82.  
83. STACK_COMMAND:  kb
84.  
85. FOLLOWUP_IP:
86. ntts!IsAdded+26 [c:\ntts\newf.h @ 92]
87. fc9e9335 83c404          add     esp,4
88.  
89. FAULTING_SOURCE_CODE:  
90.     88:
91.     89:     if (!CheckedFileName) return FALSE;
92.     90:
93.     91:     NoRegister = CheckedFileName;
94. >   92:     _wcslwr (NoRegister);
95.     93:     DPRINT ("NoRegister: %S", NoRegister);
96.     94:    
97.     95:
98.     96:
99.     97:     while (Item)
100.  
101.  
102. SYMBOL_STACK_INDEX:  4
103.  
104. SYMBOL_NAME:  ntts!IsAdded+26
105.  
106. FOLLOWUP_NAME:  MachineOwner
107.  
108. MODULE_NAME: ntts
109.  
110. IMAGE_NAME:  ntts.sys
111.  
112. DEBUG_FLR_IMAGE_TIMESTAMP:  4656c28b
113.  
114. FAILURE_BUCKET_ID:  0xBE_ntts!IsAdded+26
115.  
116. BUCKET_ID:  0xBE_ntts!IsAdded+26
117.  
118. Followup: MachineOwner
119. ---------

IceStudent видимо был прав. Я так понимаю, мне необходимо каждый раз выделять память для NoRegister и копировать CheckedFileName в нее с помощью wcscpy? Но моя функция вызывается ОЧЕНЬ часто, не приведут ли настолько частые выделения памяти опять к синему экрану?

 

DoZENT
Странный какой-то адресок

Вот эта строка из твоей функции

видишь, какой у нее адрес (8053554d), а оперирует она с содержимым по адресу 8066f15a.
Хотя, может я туплю с селекторами

Эта ошибка может быть вызвана еще и неправильным указателем. Проверь мою гипотезу (#4). Посмотри в дебуггере содержимое локальной переменной NoRegister.
Попробуй еще вариант:
LPWSTR *NoRegister = &CheckedFileName;

 

Адрес странный, согласен, на то и ошибка про запись в только читаему область..

Код (Text):

1. LPWSTR *NoRegister = &CheckedFileName;

такой вариант тоже не катит, генерит исключение или если без __try, то синий экран(

 

DoZENT
Остается только самому дебужить.

 

Это можно, только толку не будет. А чтобы синего экрана не было, надо писать _wcslwr(*NoRegister).

DoZENT

Код (Text):

1. ...
2. wchar_t szNoRegister[4096];
3.  
4. wcscpyn(szNoRegister, CheckedFileName, sizeof(szNoRegister)-1);
5. wcslwr(szNoRegister);

Но если ты CheckedFileName получаешь из UNICODE_STRING, то лучше и передавать с этим типом, т.к. завершающего нуля может и не оказаться, нужно использовать явную длину строки.

 

Чего-то я совсем запутался.... Даже приведенный выше код (4096 исправлен на 1024) не выполняется, ошибка что-то вроде PAGE_FAULT. CheckedFileName получаю из LPWSTR. Буду думать дальше...

 

Имелось ввиду если ты этот адрес берешь из структуры UNICODE_STRING, то может не оказаться завершающего нуля

 

Я понял, что имелось ввиду, нет, я не использую UNICODE_STRING.

 

А как ты вызываешь свою функцию перевода? Покажи