Bug in RegRead (REG_MULTI_SZ) Topic is solved

Report problems with documented functionality
RastaFreak
Posts: 3
Joined: 18 Aug 2022, 07:30

Bug in RegRead (REG_MULTI_SZ)

Post by RastaFreak » 18 Aug 2022, 08:28

Hi.
I'm using AutoHotkey v1.1.34.03 on Windows 7 64-bit.
My script (it's a long one, I think no code is necessary) uses SysInternals tool "MoveFile.exe to delete some log files on next reboot, and which are currently locked, like that one of Task Scheduler.
That action puts two strings in "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations" - old file name, and new file name. When deleting (locked) file,
new file name is empty string. Also, various uninstallers use that key and put stuff into it. So, in case of multiple file deletions, contents of that registry value would be:

Code: Select all

OLD_FILE_1
<empty line>
OLD_FILE_2
<empty line>
OLD_FILE_3
<empty line>
...
Next, to check if some file is already in registry, I use RegRead and documentation says that lines are retrieved, separated by new-line. But, when parser in RegRead implementation detects empty string, it stops
converting 2 x 0x00 bytes into newlines and string returned is

Code: Select all

OLD_FILE_1
<NUL>OLD_FILE_2<NUL><NUL>OLD_FILE_3<NUL><NUL>
.

It reads properly registry key into variable, but breaking that up into lines is broken.
Or maybe I'm missing something and doing something wrong. I've tested that with pre-allocated-and-zeroed variable, and using RawWrite() to check it's content.

BTW. Thanks to authors of AutoHotkey, it has really almost completely eradicated my need to use bash-shell scripts, or even C. Today, I "mastered" custom ListView sorting via SendMessage() and callback ;)

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Bug in RegRead (REG_MULTI_SZ)

Post by lexikos » 19 Aug 2022, 00:48

The REG_MULTI_SZ format is documented as follows:
A sequence of null-terminated strings, terminated by an empty string (\0). The following is an example: String1\0String2\0String3\0LastString\0\0 The first \0 terminates the first string, the second to the last \0 terminates the last string, and the final \0 terminates the sequence. Note that the final terminator must be factored into the length of the string.
Source: Registry Value Types - Win32 apps | Microsoft Docs
This can be interpreted to mean that the first occurrence of \0\0 marks the end of the value, and that is presumably the interpretation for which RegRead was designed.

It appears to be feasible to change this to use the return value of RegQueryValueEx to determine the actual end of the data.

RastaFreak
Posts: 3
Joined: 18 Aug 2022, 07:30

Re: Bug in RegRead (REG_MULTI_SZ)

Post by RastaFreak » 19 Aug 2022, 01:38

Yes, parser in RegRead is being too "smart" for its own good and breaks out of its loop on 1st occurrence of of \0\0, instead of proceeding to the end of buffer received from RegQueryValueEx(). But, since REG_MULTI_SZ can "legally" contain empty lines, that RegRead's behavior leads to information loss. All string & loop operations fail to fully process returned variable, they stop at first \0. Only way to get all the data is by using NumGet, but you still have to manually determine if variable was large enough to receive all data (and repeat process if not), and then split that raw data into lines. It can be done, but it's ugly (and contrary to documentation, since there is no mention of first empty line being "special").
Since RegQueryValueEx() can return size buffer for registry value, I think using that information is a must.

RastaFreak
Posts: 3
Joined: 18 Aug 2022, 07:30

Re: Bug in RegRead (REG_MULTI_SZ)

Post by RastaFreak » 19 Aug 2022, 03:51

Sorry, I was reading MoveFileEx() API documentation from .CHM file, instead of checking online version:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefileexw
Only in online version is that remark of REG_MULTI_SZ not "technically" supporting empty lines, but their example clearly shows using it. Windows boot subsystem supports it, Windows API supports it, Microsoft tools support it (SysInternals), and many of uninstallers are relying on it, so I believe AutoHotkey should also support it.

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Bug in RegRead (REG_MULTI_SZ)

Post by lexikos » 19 Aug 2022, 07:58

I didn't need convincing. I already added it to my list.

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: Bug in RegRead (REG_MULTI_SZ)  Topic is solved

Post by lexikos » 23 Aug 2022, 02:55

Fixed by v1.1.34.04.

Post Reply

Return to “Bug Reports”