COMMAND

    SCM

SYSTEMS AFFECTED

    WinNT 4.0

PROBLEM

    Daniel Crichton found following.  He came across a problem on  his
    NT4 Server SP5 (no hot  fixes) machine whereby having 2  dirs with
    similar names  can confuse  the SCM  when the  same named EXE file
    exists in both.  Testing was  done with a beta version of  WebSite
    2.4, and Daniel  decided to keep  a copy of  the final release  on
    the same server in  case he needed to  swap them.  The  WS service
    lives   in   c:\website,   and   he   called   the   copy  version
    c:\website 2.3.18  (notice the  space).   Installing the  new beta
    over the version in c:\website worked perfectly, and starting  the
    service via RemotelyAnywhere 2.40  (which uses only the  Win32 API
    to start/stop services) worked fine too.  However, Daniel  decided
    to reboot  his server  and found  that WebSite  2.3.18 started  up
    (automatic  startup  in  SCM)  from  the  c:\website  2.3.18  dir.
    Stopping   the   service   and    restarting   it   (again    from
    RemotelyAnywhere) still caused the older version to run.

SOLUTION

    Stop the service, rename the dir to c:\xwebsite 2.3.18, and  start
    the service again, and this time 2.4.7 will start up as  expected.
    Guess is that the SCM is  unable to deal with spaces in  dir names
    correctly.  That sounds  like it is related  to a problem in  COM,
    DCOM.  See KB article Q179690 for more information on this.

    According to Microsoft:  This problem is  caused by the  fact that
    unquoted  long  file  names  containing  spaces  are  ambiguous to
    CreateProcess    (which    is    called    by    CoCreateInstance/
    CoGetClassObject). Refer  to the  CreateProcess documentation  for
    more information.

    The solution they propose is  to register all of your  COM objects
    using short file names (the 8.3 version).  Sounds to me like  this
    has some interesting potential.   If what Microsoft writes in  the
    KB is  true, then  anybody that  calls CreateProcess  with a  long
    filename could end  up opening an  unexpected dummy file  instead.
    Many  process  are  created  from  Program Files, which happens to
    have a space.