Windows 2003 Server; Unable to add registry entries?

Archive: Windows 2003 Server; Unable to add registry entries?

zimsms
13th September 2004 14:14 UTC

Windows 2003 Server; Unable to add registry entries?
Hello All,

I'm running into an issue with my installer on Windows 2003 Server; in regards to the registry. I', an admin user and therefore have complete privileges. If I use regedit i can add a key no probblem, however, if I use the installer which works on all the other windows operating systems, it fails to add any of the registry keys. I'm using a pretty simple macro to do this:


  !macro CreateRegVarIfNotExist UPDATE TYPE ROOT KEY NAME VALUE
  ; Update: 1= Yes, 0 = No
  ; Type One of: STRING, STRINGEX, DWORD, HEX
    push $R0
    !define Index 'Line${__LINE__}'
    !insertmacro IfKeyExists "${ROOT}" "${KEY}" "${NAME}"
    Pop $R0
    ;$R0 contains 0 (not present) or 1 (present)

    IntCmp "$R0" "1" "${Index}-Exists" 0
    StrCmp "${TYPE}" "STRING" 0 +3
      WriteRegStr "${ROOT}" "${KEY}" "${NAME}" "${VALUE}"
      Goto "${Index}-Done"
    StrCmp "${TYPE}" "STRINGEX" 0 +3
      WriteRegExpandStr "${ROOT}" "${KEY}" "${NAME}" "${VALUE}"
      Goto "${Index}-Done"
    StrCmp "${TYPE}" "DWORD" 0 +3
      WriteRegDWord "${ROOT}" "${KEY}" "${NAME}" "${VALUE}"
      Goto "${Index}-Done"
!ifdef _HEXED_
    StrCmp "${TYPE}" "HEX" 0 +3
      WriteRegBin "${ROOT}" "${KEY}" "${NAME}" "${VALUE}"
      Goto "${Index}-Done"
!endif

    "${Index}-Exists:"
    ; update?
    IntCmp "${UPDATE}" "0" "${Index}-Done" 0
    StrCmp "${TYPE}" "STRING" 0 +3
      WriteRegStr "${ROOT}" "${KEY}" "${NAME}" "${VALUE}"
      Goto "${Index}-Done"
    StrCmp "${TYPE}" "STRINGEX" 0 +3
      WriteRegExpandStr "${ROOT}" "${KEY}" "${NAME}" "${VALUE}"
      Goto "${Index}-Done"
    StrCmp "${TYPE}" "DWORD" 0 +3
      WriteRegDWord "${ROOT}" "${KEY}" "${NAME}" "${VALUE}"
      Goto "${Index}-Done"
!ifdef _HEXED_
    StrCmp "${TYPE}" "HEX" 0 +3
      WriteRegBin "${ROOT}" "${KEY}" "${NAME}" "${VALUE}"
      Goto "${Index}-Done"
!endif

    "${Index}-Done:"
    !undef Index
    pop $R0
 !macroend

 !macro IfKeyExists ROOT MAIN_KEY KEY
   push $R0
   push $R1

   !define IKEIndex 'Line${__LINE__}'

   StrCpy $R1 "0"

   "${IKEIndex}-Loop:"
   ; Check for Key
   EnumRegKey $R0 ${ROOT} "${MAIN_KEY}" "$R1"
   StrCmp $R0 "" "${IKEIndex}-False"
     IntOp $R1 $R1 + 1
     StrCmp $R0 "${KEY}" "${IKEIndex}-True" "${IKEIndex}-Loop"

   "${IKEIndex}-True:"
   ;Return 1 if found
   push "1"
   goto "${IKEIndex}-End"

   "${IKEIndex}-False:"
   ;Return 0 if not found
   push "0"
   goto "${IKEIndex}-End"

   "${IKEIndex}-End:"
   !undef IKEIndex
   exch 2
   pop $R0
   pop $R1
 !macroend

Which you'd call like:


    ; ODBC Driver
    !insertmacro CreateRegVarIfNotExist 1 "STRING" HKLM "Software\ODBC\ODBCINST.INI\ODBC Drivers" "$(DESC_ODBC_DRIVER)"  "Installed"
    !insertmacro CreateRegVarIfNotExist 1 "STRING" HKLM "Software\ODBC\ODBCINST.INI\$(DESC_ODBC_DRIVER)" "CPTimeout" "<not pooled>"
    !insertmacro CreateRegVarIfNotExist 1 "STRING" HKLM "Software\ODBC\ODBCINST.INI\$(DESC_ODBC_DRIVER)" "Driver" "$INSTDIR\myodbc.dll"
    !insertmacro CreateRegVarIfNotExist 1 "STRING" HKLM "Software\ODBC\ODBCINST.INI\$(DESC_ODBC_DRIVER)" "Setup" "$INSTDIR\myodbc.dll"

Anyone have any ideas as to why I'm unable to add registry keys?

Davion
13th September 2004 14:34 UTC

if it's urgent try to work around the Problem with regfiles which you copy into a tmp folder, execute the reg files and the delete them... no other Idea... but I try to test it on our win2003 machine within the next days

greetz Dave

zimsms
13th September 2004 17:25 UTC

I believe WriteRegStr is broken on Windows Server 2003. No matter what I try to add to the registry via this command it fails to be added. I am logged on as the administrator. Any ideas?

kichik
13th September 2004 18:04 UTC

Are you sure it's not some scripting error? Have you tested it with just WriteRegStr?

zimsms
13th September 2004 18:33 UTC

Kichik, the following script will demonstrate the error. It's a modified Basic.nsi that copies no files, but does try to create 4 registry entries, two under HKCU and two under HKLM. The ones under HKCU get created, the ones under HKLM do not. I am the administrator, is there something special I need to do or is this a bug?

kichik
13th September 2004 18:41 UTC

Can you compile it with logging enabled and attach the log?

zimsms
13th September 2004 18:50 UTC

yeah ok, where is config.h kept? I modified modifiedbasic.nsi to contain the "LogSet on" command, but where is this config.h I have to put the define in?

kichik
13th September 2004 18:53 UTC

Source\exehead\config.h.

You can also download a prebuilt makensis with logging from the download page.

zimsms
13th September 2004 19:07 UTC

Here are the complete contents of the install.log file as requested. I placed the LogSet around the main install section.


WriteRegStr: set -2147483647\Software\Modern UI Test\ to C:\Program Files (x86)\Modern UI Test
WriteRegStr: set -2147483647\Software\Modern UI Test\Bacon to Bits
WriteRegStr: set -2147483646\Software\Modern UI Test\ to C:\Program Files (x86)\Modern UI Test
WriteRegStr: set -2147483646\Software\Modern UI Test\Bacon to Bits
created uninstaller: 863, "C:\Program Files (x86)\Modern UI Test\Uninstall.exe"
settings logging to 0

kichik
13th September 2004 19:14 UTC

Is the error flag set?

zimsms
13th September 2004 19:29 UTC

No the error flag was not set.

kichik
13th September 2004 20:58 UTC

That's weird... According to all the information you've provided, the string is written successfully. Maybe it writes it to some special registry just like the program files folder is located in C:\Program Files (x86)\ and not C:\Program Files\. Did you try adding a ReadRegStr line to see if at least the installer itself can read those values?

zimsms
13th September 2004 21:11 UTC

Yeah, unfortunately it doesn't find them.

Perhaps the call in the NSIS source is 32bit only and not 64bit, and therefore doesn't function the same? Just an idea. The files, shortcuts and everything else get placed and created properly, just the HKLM registry items seem to be missing in action.

That or perhaps HKLM entries need an extra security permission applied.

kichik
13th September 2004 21:31 UTC

I have to go, I'll be back tomorrow. The code is in Source\exehead\exec.c line 1160 (case EW_WRITEREG: //write registry value). Mind doing some tests with it? A few things I can think of:

RegCreateKey->RegCreateKeyEx
SetLastError and GetLastError around RegSetValueEx to see if there is some error even if the return value says there isn't
Use RegQueryValueEx with the open HKEY
Replace RegSetValueEx with RegSetValueExW
Add a few NULLs to data/buf2
RegFlushKey

zimsms
14th September 2004 13:56 UTC

I just got your message, I'll try a few things here.

zimsms
14th September 2004 14:32 UTC

hmm, Most of the existing functions in that code are labeled as obsolete, and are only provided for 16 bit apps. Ouch. It needs a good rewrite. It's too bad really, M$ made something so easy extremely painful by incorporating all the new security stuff into it. Not only will the user have to do it twice (security based on pre XP SP2, but for SP2 as well).

zimsms
14th September 2004 17:04 UTC

Here's a pseudo markup of the new additions that will have to be made to the registry functions. I'm not sure if these are backwards compatible. Unfortunately that's all the time I had to spare. The class is not complete and is not functional. It basically demonstrates how security is done when creating a registry key. Anyways, hope it speeds up a fix, for someone that has time to spare.

kichik
14th September 2004 20:12 UTC

Obsolete doesn't mean it shouldn't work. If it's provided for compatibility it should still work.

Have you tried replacing RegOpenKey with RegOpenKeyEx and made sure it worked? It's not clear from your message if you got it working or just found that some deprecated APIs are used (on purpose, by the way).

zimsms
15th September 2004 15:54 UTC

I tried to change the source you specified to use the new format, however, that implies adding all the security information as well; as I stated in a previous post. I did not have the time to make the modifications to your source. All of the functions appear to work properly except for Key creation. The key creation will require modifying the NSIS source to support RegCreateKeyEX using the security attributes structure, as specified in the RegCreateKeyEx documentation. Until this has been done registry keys will appear to be created, (since no errors are reported), but the keys never get created when using the WriteReg* functions.

Microsoft states:

Obsolete Functions

These functions are provided ONLY for compatibility with 16-bit versions of Windows:

RegCreateKey
RegEnumKey
RegOpenKey
RegQueryValue
RegSetValue

It looks like they are no longer supported when running against a 32 or 64 bit OS, as of the release of the Windows 2003 Product Family.

kichik
15th September 2004 16:34 UTC

You can simply specify NULL for lpSecurityAttributes.

If lpSecurityAttributes is NULL, the key gets a default security descriptor. The ACLs in a default security descriptor for a key are inherited from its direct parent key.

You can see how RegCreateKeyEx is used in all the other registry instructions.

zimsms
15th September 2004 16:46 UTC

hmmm, interesting....

Yathosho
15th September 2004 23:49 UTC

i'm using win2003 myself, and i doubt it's an issue with the OS, never had problems writing regkeys in nsis..

JeronimoColon
24th September 2004 16:20 UTC

Yathosho,
Have you tried zimsms sample script? - Just curious...

zimsms,
What version of WS2K3 are you using?
Also, I read a technote about some weirdness with WS2K3 and registry permision if you have TS install. I believe it doesn't matter whether or not your actually using TS at the time your writing to the registry. If this turns out to be the source of the problem I believe M$ has issued a patch - by direct request of coarse...

Either way I'll try it this weekend. I'll log-in with each default security group i.e. User, Power User, Admin, etc. and report my findings.

jc3

Yathosho
24th September 2004 19:10 UTC

i have just tested it, works perfectly.

talking on icq with kichik, we came to the conclusion, that this appears to be an issue with the "Program Files (x86)" directory in the 64bit version.

JeronimoColon
25th September 2004 06:35 UTC

I'm just curious and want to understand this a little further...
What's the correlation between "Program Files (x86)" directory and zimsms registry problem? :confused:

Thanks,

jc3

Yathosho
25th September 2004 09:58 UTC

sorry, i just figured what bullshit i was typing there. it was of course not related to the name of that directory, we just talked about it, to spot whether it might be an 64-bit issue. at least a hint.

i guess you have to wait for kichik's word on that, since i havn't followed the problem since.

Rawk
24th May 2005 18:01 UTC

If you are running Windows Server 2003 64 bit, then yes entries into the registry by a 32 bit program are redirected in the same way as 32 bit programs accessing /system32 or /program files are redirected.

http://msdn.microsoft.com/library/de...redirector.asp

HTH