Win32 Env variable Pitfall of mismatching SetEnvironmentVariable and getEnv

Problem Description

Below article will give a brief introduction on environment variables and one strange (for a Unix programmer) behavior in WIN32. 
i.e getEnv() does not retrieve some environment variable but retrieve some in WIN32. But in Unix, all environment variables are retrieved.

Background

As quoted in wiki -

Environment variables are a set of dynamically named values that can affect the way running processes will behave. (http://en.wikipedia.org/wiki/Environment_variable )

In Unix environment, it is usual to set environment variables in 2 ways -

• Type 1 setting : Use setenv command (generally collect these command into a environment sourcing file) and call it to set all the environment variables.

• Type 2 setting : Use setenv API provided in the stdlib library and set the environment variables. API Info - http://pubs.opengroup.org/onlinepubs/007904975/functions/setenv.html

A point of note : The first option is executed from the shell command and all these environment variables are inherited by the process - it is more of a statically set environment variable. The second option is a more dynamic option which can be set during the process execution.

These variables, thus set can be accessed with getEnv ( http://pubs.opengroup.org/onlinepubs/009695399/functions/getenv.html) again available from stdlib.

Now, let us come to the crux of the problem.

In Unix, both the environment variables set by "Type 1" and "Type 2" can be accessed by getEnv function. When this code is ported in WIN32, it is strangely seen that statically set environment variables only will be accessible for getEnv function.

Any environment variable set using "Type2" setting (i.e dynamically set variable) using setEnvironmentVariable API (http://msdn.microsoft.com/en-us/library/ms686206%28v=vs.85%29.aspx) cannot be accessed by getEnv() function.

Example

Let us take a look at below code

Example 1

(In command line, setenv LIB="c:\\mylib;c:\\yourlib" is already done)-

1:  #include <stdlib.h>  
2:  #include <stdio.h>  
3:  int main( void )  
4:  {  
5:  char *libvar;  
6:  /* Get new value. */  
7:  libvar = getenv( "LIB" );  
8:  if( libvar != NULL )  
9:  printf( "New LIB variable is: %s\n", libvar );  
10:  return 0;  
11:  }  

In the above case, we will be able to get the output with detailed environment variable set from command line.

However, the below example has a start change in behavior 

Example 2

(In command line, LIB="c:\\mylib;c:\\yourlib" is not set from command line, but set in program)-

1:    #include <stdlib.h>  
2:    #include <stdio.h>  
3:    int main( void )  
4:    {  
5:      char *libvar;  
6:      SetEnvironmentVariable("LIB", "C:\WIN32");  
7:      /* Get new value. */  
8:      libvar = getenv( "LIB" );  
9:      if( libvar != NULL )  
10:       printf( "New LIB variable is: %s\n", libvar );  
11:     return 0;  
12:    } 

Here, the output would not be printed, owing to the fact that Type 2 setting env variables are not obtained by the getenv() API.

Root cause

The getEnv() function provides the output only from the internal cache (data structures) populated during the process start-up i.e the environment variable set in the shell. This is mentioned in the MSDN manual -

getenv operates only on the data structures accessible to the run-time library and not on the environment "segment" created for the process by the operating system

Thus in WIN32, getEnv() will not reflect the environment variable set during the execution of the program. Instead users need to use GetEnvironmentVariableA() API provided by MSDN.

Take Away's

• Developers needs to be very discreet in using API's and also checking for differing "meanings" across different OS.

• The manual should be read in detail and "in the corner" mentioning of the difference in behavior must be checked with a magnifying lens.

Regards,

Tech Unravel.

Supreme Debugging

[Windows Programming] : Exception Generation during process creation or system command execution

Problem Description


During my windows porting activity (Existing code base in *ix - CPP programming language)
I came across a very strange problem

The project code bases uses many system command for various activity,
and one such operation is to untar (unrar in windows) the package to be launched.

Strangely the problem faced was that the unrar command used was not working as expected in XP SP3 patch.
Instead for both error and success scenario strange error code was displayed.
Below steps provides an insight with the investigation steps and the final end result.


Investigation Steps

Step 1: The initial suspect was related to compatibility of system command in Windows.
Unlike *ix, where the command is very well defined, it was hard to find out a suitable documentation for the same in
windows.

So immediately suspect was API issue (compatibility problem).

Step 2: Next the focus shifted to an well established, command execution methodology. Immediate reference came
from MSDN content -

http://msdn.microsoft.com/en-us/library/ms682425%28v=vs.85%29.aspx

Step 3: A sample program was derived - which used the createProcess API was used for untarring.

Sample code looked as shown below

1:  int main()  
2:  {  
3:  string ProgramName = "C:\\Program Files\\WinRAR\\WinRAR.exe";  
4:  STARTUPINFO StartupInfo;  
5:  PROCESS_INFORMATION ProcessInfo;  
6:  memset(&StartupInfo, 0, sizeof(STARTUPINFO));  
7:  memset(&ProcessInfo, 0, sizeof(PROCESS_INFORMATION);  
8:  if (CreateProcess((LPCTSTR)ProgramName.c_str(),(LPCTSTR)"WinRAR.exe x -y -ibck d:\\abc.tar d:\\"),NULL,  
9:  NULL,  
10:  FALSE,  
11:  NORMAL_PRIORITY_CLASS,  
12:  NULL,  
13:  NULL,  
14:  &StartupInfo,  
15:  &ProcessInfo) == 0)  
16:  {  
17:  string tmpStr("Error executing");  
18:  tmpStr += ProgramName;  
19:  cout<<"StmtDesigner"<<<"createprocess dword="" exitcode="0;" if="" span="" string="" tmpstr="">  
20:  }  
21:  CloseHandle(ProcessInfo.hProcess);  
22:  CloseHandle(ProcessInfo.hThread);  
23:  getch();  
24:  return 0;  
25:  }

In this case strangely,
SP2 provided expected result - i.e 0 for success and 1 (non-zero) for failure.
SP3 provided unexpected result - i.e 3221225477 for both success and failure.

Step 4:
The exit code value - 3221225477 was very critical, now when this was transformed
into HEX,it represented - C0000005 - which represents access violation in windows.
Now the investigation took a turn on what could have lead to the problem.

Step 5:
With lot of google'ing and detailed search, It was found that a good utility
called "Process Monitor" would mimic the functionality of strace in Unix.

http://technet.microsoft.com/en-us/sysinternals/bb896645

Was downloaded and on SP3 machine and the sample program above was run with
monitor tool.

Step 6:
Process Monitor helped (with very good filtering feature) to find out that
WinRar process exited with exception.

This was noted as an event in the Process Monitor,
Further analysis of the stack during the Winrar exit event showed that the
$WINDOWS/system32/ntdll.dll interacted with one of the proprietary library present
in the same path thus the exit status was not captured correctly as ntdll.dll
was trying to access some function of proprietary library - causing access violation.

This was cross confirmed by SP2 machine - which did not have this dll file
(and program was executed successfully).

Also after renaming/removing the proprietary library from system32 directory,
the operation succeeded even in SP3 operation (both createProcess and system command)

Take Away's

1. It is still unclear why the presence of proprietary application library in
$WINDOWS/system32 caused ntdll.dll to fail thread/process exit for WinRar application.

2. Exceptions are also thrown by the API's GetExitCodeProcess.
So it is not restricted to a range of values.

3. Placing proprietary application in the system32 location was not a good idea.
No thought on its impact was done.

4. Process Monitor is an excellent tool and is one of the must haves for the windows
developer.

5. Whenever C0000005 and other exceptions are the outcome of a program, program and
its system dependency must be thoroughly checked for all kinds of violation
(In this case an unwanted library causing some kind of interference).

6. Initial suspect on SP2/SP3 difference proved futile and invalid,
afterall looks like windows is maintaining good backward compatibility :).


Regards,
Tech Unravel
Supreme Debugging