Thread: Windows x86-64 One-Click Install (9.1.2-1, 9.0.6-1) hangs on "initialising the database cluster" (with work-around)

Windows 7 Home Premium 64-bit, SP 1
Intel Core i7-2630QM @ 2.00 GHz
Local machine authentication (no network-based login)

Installation of the 9.1.2-1 and 9.0.6-1 hangs on "initialising the database cluster". Process has 0 CPU. In all scenarios left process run for at least 5 minutes up to an hour.

Tried various configurations, and I'll attempt to list them here
Config 1
    Locale = Default
    Install to = C:\Program Files\PostgreSQL\9.1
    Data Dir = D:\postgres\9.1\data   
    Created new postgres user as part of the installer
    Hung at "initialising the database cluster"

Config 2
    Locale = Default
    Install to = C:\PostgreSQL\9.1
    Data Dir = D:\postgres\9.1\data
    postgres user already created in Config 1 step
    Hung at "initialising the database cluster"

Config 3
    Added "FULL" permissions to D:\postgres; C:\PostgreSQL; (recursive) for postgres user
    Hung at "initialising the database cluster"

Config 4
    Locale = English, United States
    Hung at "initialising the database cluster"



After some experimentation (sorry, can't help this as a software developer!), I was able to reproduce the problem with this set of scripts. The original file where the execution hangs is:

    initicluster.vbs line 117
    Function DoCMd(strCmd)
        ...
        DoCmd = objShell.Run(objTempFolder.Path & "\" & strBatchFile, 0, True)
        ...
    End Function

[sayhi.bat]
echo Hello World > _hello.txt

[test.vbs]
Dim objShell
Set objShell = WScript.CreateObject("WScript.Shell")

' original script as window style (param 2) set to 0 to hide the command prompt
' setting window style to "1" here shows that the cmd prompt is not executing the batch file
objShell.Run "sayhi.bat", 1, True

---------------------
Run the above command in an Administrator command prompt with:
    cscript test.vbs

Program will hangs, does not generate the _hello.txt file

I was not able to discover any permissions that prevented a batch file from being run directly by wscript, but I did find two changes that made this work:
---------------------
[test.vbs]
' Reference: http://technet.microsoft.com/en-us/library/ee692837.aspx

' SOLUTION 1: Launch cmd.exe instead of launching the batch file directly
objShell.Run "%COMSPEC% /c sayhi.bat", 1, True

' SOLUTION 2: Use Shell.Exec instead of Shell.Run
objShell.Exec "sayhi.bat > _exec.txt"
---------------------

After discovering these changes:
1. opened initcluster.vbs in Komodo Edit 6.1
2. modified line ~113 to:

    DoCmd = objShell.Run("%COMSPEC% /c " & objTempFolder.Path & "\" & strBatchFile, 0, True)

3. canceled the hung postgres install
    -- this deleted the initcluster.vbs
4. save initcluster.vbs and marked as read-only
5. re-run the install
6. watch for initcluster.vbs date to change during installation unpacking
7. save initcluster.vbs when date on file changes

At this point the data directory is created properly and the installation progresses beyond  "initialising the database cluster" but is now hung on "Configuring database server startup"

8. searched for ".Run" in all .vbs files
9. found matching line in startupcfg.vbs and loadmodules.vbs
10. modified startupcfg.vbs line 42

    DoCmd = objShell.Run("%COMSPEC% /c " & objTempFolder.Path & "\" & strBatchFile, 0, True)

11. modified loadmodules.vbs line 47

    DoCmd = objShell.Run("%COMSPEC% /c " & objTempFolder.Path & "\" & strBatchFile, 0, True)

12. delete old data directory
13. repeat steps 1-7, then jump to 14
14. save startupcfg.vbs and loadmodules.vbs (immediately after initcluster.vbs has been re-saved)

Install runs through completely and successfully.

Attached is a zip of the 3 .vbs files modified (renamed to ._vbs to avoid firewall problems).

Hope this helps!
Thanks,
Eric

On Thu, Jan 26, 2012 at 12:36 AM, Eric Borts <eborts@bltek.com> wrote:
> Windows 7 Home Premium 64-bit, SP 1
> Intel Core i7-2630QM @ 2.00 GHz
> Local machine authentication (no network-based login)
>
> Installation of the 9.1.2-1 and 9.0.6-1 hangs on "initialising the database
> cluster". Process has 0 CPU. In all scenarios left process run for at least
> 5 minutes up to an hour.
>
> Tried various configurations, and I'll attempt to list them here
> Config 1
>     Locale = Default
>     Install to = C:\Program Files\PostgreSQL\9.1
>     Data Dir = D:\postgres\9.1\data
>     Created new postgres user as part of the installer
>     Hung at "initialising the database cluster"
>
> Config 2
>     Locale = Default
>     Install to = C:\PostgreSQL\9.1
>     Data Dir = D:\postgres\9.1\data
>     postgres user already created in Config 1 step
>     Hung at "initialising the database cluster"
>
> Config 3
>     Added "FULL" permissions to D:\postgres; C:\PostgreSQL; (recursive) for
> postgres user
>     Hung at "initialising the database cluster"
>
> Config 4
>     Locale = English, United States
>     Hung at "initialising the database cluster"
>
>
>
> After some experimentation (sorry, can't help this as a software
> developer!), I was able to reproduce the problem with this set of scripts.
> The original file where the execution hangs is:
>
>     initicluster.vbs line 117
>     Function DoCMd(strCmd)
>         ...
>         DoCmd = objShell.Run(objTempFolder.Path & "\" & strBatchFile, 0,
> True)
>         ...
>     End Function
>
> [sayhi.bat]
> echo Hello World > _hello.txt
>
> [test.vbs]
> Dim objShell
> Set objShell = WScript.CreateObject("WScript.Shell")
>
> ' original script as window style (param 2) set to 0 to hide the command
> prompt
> ' setting window style to "1" here shows that the cmd prompt is not
> executing the batch file
> objShell.Run "sayhi.bat", 1, True
>
> ---------------------
> Run the above command in an Administrator command prompt with:
>     cscript test.vbs
>
> Program will hangs, does not generate the _hello.txt file
>
> I was not able to discover any permissions that prevented a batch file from
> being run directly by wscript, but I did find two changes that made this
> work:
> ---------------------
> [test.vbs]
> ' Reference: http://technet.microsoft.com/en-us/library/ee692837.aspx
>
> ' SOLUTION 1: Launch cmd.exe instead of launching the batch file directly
> objShell.Run "%COMSPEC% /c sayhi.bat", 1, True
>
> ' SOLUTION 2: Use Shell.Exec instead of Shell.Run
> objShell.Exec "sayhi.bat > _exec.txt"
> ---------------------
>
> After discovering these changes:
> 1. opened initcluster.vbs in Komodo Edit 6.1
> 2. modified line ~113 to:
>
>     DoCmd = objShell.Run("%COMSPEC% /c " & objTempFolder.Path & "\" &
> strBatchFile, 0, True)
>
> 3. canceled the hung postgres install
>     -- this deleted the initcluster.vbs
> 4. save initcluster.vbs and marked as read-only
> 5. re-run the install
> 6. watch for initcluster.vbs date to change during installation unpacking
> 7. save initcluster.vbs when date on file changes
>
> At this point the data directory is created properly and the installation
> progresses beyond  "initialising the database cluster" but is now hung on
> "Configuring database server startup"
>
> 8. searched for ".Run" in all .vbs files
> 9. found matching line in startupcfg.vbs and loadmodules.vbs
> 10. modified startupcfg.vbs line 42
>
>     DoCmd = objShell.Run("%COMSPEC% /c " & objTempFolder.Path & "\" &
> strBatchFile, 0, True)
>
> 11. modified loadmodules.vbs line 47
>
>     DoCmd = objShell.Run("%COMSPEC% /c " & objTempFolder.Path & "\" &
> strBatchFile, 0, True)
>
> 12. delete old data directory
> 13. repeat steps 1-7, then jump to 14
> 14. save startupcfg.vbs and loadmodules.vbs (immediately after
> initcluster.vbs has been re-saved)
>
> Install runs through completely and successfully.
>
> Attached is a zip of the 3 .vbs files modified (renamed to ._vbs to avoid
> firewall problems).

Dharmendra, can you look into this please?

Eric, is there anything unusual about the configuration of your
machine? Suffice it to say, this doesn't normally happen.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 1/26/2012 1:17 AM, Dave Page wrote:
> Dharmendra, can you look into this please?
>
> Eric, is there anything unusual about the configuration of your
> machine? Suffice it to say, this doesn't normally happen.
>
Hi Dave, I'm guessing the answer to that question is "yes". The machine
came preinstalled with Norton Internet Security, but this was turned off
when I ran the install. After further investigation to the .bat file, I
realized that I am also missing the "Edit" option when I right click a
batch file.

I investigated, uninstalled stuff, disabled a lot of stuff in my
registry, and nearly bricked my computer. After three hours, I'm going
to have to ask for suggestions. Here's what I found/tried:

1. uninstalled Norton Internet Security (and rebooted)
2. uninstalled Acrobat Reader
3. disabled all ContextMenuHandlers by
     a. renaming HKCR/*/shellex to oldshellex
     b. renaming HKCR/AllFileSystemsObjects/shellex to oldshellex
     c. tried, but was unable to rename HKCR/batfile/ShellEx, so renamed
HKCR/batfile/ShellEx/ContextMenuHandlers to oldContextMenuHandlers
4. disabled all non-Microsoft shell extensions using ShellExView
<http://www.nirsoft.net/utils/shexview.html>
5. rebooted - computer bricked (black screen when Windows should be loading)
6. booted in safe mode
7. tested script (from my original response) and right click.
     a. no Edit option in batch file context menu
     b. script hung as before
8. Undid steps 3 and 4 in safe mode
9. Rebooted - booted into windows properly
10. Still no Edit in context menu and script still hangs

I'm open to suggestions. I think it might be related to Edit menu
missing from my batch file, as this is the only odd thing that I can
tell about my machine. I have another similar machine (earlier model
Vaio) that both has the Edit menu and runs the test script successfully.
I compared the HKCR/batfile registry trees (using TortoiseSVN diff) and
they are identical. Short of comparing the entire registry I'm at a loss.

Would it be too dangerous to use WScript.Shell.Exec or to use
WScript.Shell.Run "%COMPSEC% /c" ? This has been an 11 hour struggle for
me so far, and I know at least a few others have had this same problem.
Here is a link to my work around on enterprisedb
<http://forums.enterprisedb.com/posts/list/2870.page#11379>.

Thanks,
Eric

Reference Links:
http://www.pcreview.co.uk/forums/edit-print-open-missing-shell-context-menu-cmd-and-bat-files-t2551124.html
http://windowsxp.mvps.org/slowrightclick.htm
http://www.nirsoft.net/utils/shexview.html

Also, here is a link to the same issue on StackOverflow:
http://stackoverflow.com/questions/3559719/wscript-shell-run-doesnt-work-consistently

Also solved using %COMSPEC% /c, though it doesn't say why this is a problem.

Cheers,
Eric

On 1/26/2012 11:37 AM, Eric Borts wrote:
> On 1/26/2012 1:17 AM, Dave Page wrote:
>> Dharmendra, can you look into this please?
>>
>> Eric, is there anything unusual about the configuration of your
>> machine? Suffice it to say, this doesn't normally happen.
>>
> Hi Dave, I'm guessing the answer to that question is "yes". The
> machine came preinstalled with Norton Internet Security, but this was
> turned off when I ran the install. After further investigation to the
> .bat file, I realized that I am also missing the "Edit" option when I
> right click a batch file.
>
> I investigated, uninstalled stuff, disabled a lot of stuff in my
> registry, and nearly bricked my computer. After three hours, I'm going
> to have to ask for suggestions. Here's what I found/tried:
>
> 1. uninstalled Norton Internet Security (and rebooted)
> 2. uninstalled Acrobat Reader
> 3. disabled all ContextMenuHandlers by
>     a. renaming HKCR/*/shellex to oldshellex
>     b. renaming HKCR/AllFileSystemsObjects/shellex to oldshellex
>     c. tried, but was unable to rename HKCR/batfile/ShellEx, so
> renamed HKCR/batfile/ShellEx/ContextMenuHandlers to oldContextMenuHandlers
> 4. disabled all non-Microsoft shell extensions using ShellExView
> <http://www.nirsoft.net/utils/shexview.html>
> 5. rebooted - computer bricked (black screen when Windows should be
> loading)
> 6. booted in safe mode
> 7. tested script (from my original response) and right click.
>     a. no Edit option in batch file context menu
>     b. script hung as before
> 8. Undid steps 3 and 4 in safe mode
> 9. Rebooted - booted into windows properly
> 10. Still no Edit in context menu and script still hangs
>
> I'm open to suggestions. I think it might be related to Edit menu
> missing from my batch file, as this is the only odd thing that I can
> tell about my machine. I have another similar machine (earlier model
> Vaio) that both has the Edit menu and runs the test script
> successfully. I compared the HKCR/batfile registry trees (using
> TortoiseSVN diff) and they are identical. Short of comparing the
> entire registry I'm at a loss.
>
> Would it be too dangerous to use WScript.Shell.Exec or to use
> WScript.Shell.Run "%COMPSEC% /c" ? This has been an 11 hour struggle
> for me so far, and I know at least a few others have had this same
> problem. Here is a link to my work around on enterprisedb
> <http://forums.enterprisedb.com/posts/list/2870.page#11379>.
>
> Thanks,
> Eric
>
> Reference Links:
> http://www.pcreview.co.uk/forums/edit-print-open-missing-shell-context-menu-cmd-and-bat-files-t2551124.html
> http://windowsxp.mvps.org/slowrightclick.htm
> http://www.nirsoft.net/utils/shexview.html
>

iirc, using %COMSPEC% /c will cause the scripts to run in a visible
command window, which is pretty ugly, and doesn't seem to be necessary
anywhere except on your machine!

What's the output from the "set" command on that box?

On Thu, Jan 26, 2012 at 6:54 PM, Eric Borts <eborts@bltek.com> wrote:
> Also, here is a link to the same issue on StackOverflow:
> http://stackoverflow.com/questions/3559719/wscript-shell-run-doesnt-work-=
consistently
>
> Also solved using %COMSPEC% /c, though it doesn't say why this is a probl=
em.
>
> Cheers,
> Eric
>
>
> On 1/26/2012 11:37 AM, Eric Borts wrote:
>
> On 1/26/2012 1:17 AM, Dave Page wrote:
>
> Dharmendra, can you look into this please?
>
> Eric, is there anything unusual about the configuration of your
> machine? Suffice it to say, this doesn't normally happen.
>
> Hi Dave, I'm guessing the answer to that question is "yes". The machine c=
ame
> preinstalled with Norton Internet Security, but this was turned off when I
> ran the install. After further investigation to the .bat file, I realized
> that I am also missing the "Edit" option when I right click a batch file.
>
> I investigated, uninstalled stuff, disabled a lot of stuff in my registry,
> and nearly bricked my computer. After three hours, I'm going to have to a=
sk
> for suggestions. Here's what I found/tried:
>
> 1. uninstalled Norton Internet Security (and rebooted)
> 2. uninstalled Acrobat Reader
> 3. disabled all ContextMenuHandlers by
> =A0=A0=A0 a. renaming HKCR/*/shellex to oldshellex
> =A0=A0=A0 b. renaming HKCR/AllFileSystemsObjects/shellex to oldshellex
> =A0=A0=A0 c. tried, but was unable to rename HKCR/batfile/ShellEx, so ren=
amed
> HKCR/batfile/ShellEx/ContextMenuHandlers to oldContextMenuHandlers
> 4. disabled all non-Microsoft shell extensions using ShellExView
> 5. rebooted - computer bricked (black screen when Windows should be loadi=
ng)
> 6. booted in safe mode
> 7. tested script (from my original response) and right click.
> =A0=A0=A0 a. no Edit option in batch file context menu
> =A0=A0=A0 b. script hung as before
> 8. Undid steps 3 and 4 in safe mode
> 9. Rebooted - booted into windows properly
> 10. Still no Edit in context menu and script still hangs
>
> I'm open to suggestions. I think it might be related to Edit menu missing
> from my batch file, as this is the only odd thing that I can tell about my
> machine. I have another similar machine (earlier model Vaio) that both has
> the Edit menu and runs the test script successfully. I compared the
> HKCR/batfile registry trees (using TortoiseSVN diff) and they are identic=
al.
> Short of comparing the entire registry I'm at a loss.
>
> Would it be too dangerous to use WScript.Shell.Exec or to use
> WScript.Shell.Run "%COMPSEC% /c" ? This has been an 11 hour struggle for =
me
> so far, and I know at least a few others have had this same problem. Here=
 is
> a link to my work around on enterprisedb.
>
> Thanks,
> Eric
>
> Reference Links:
> http://www.pcreview.co.uk/forums/edit-print-open-missing-shell-context-me=
nu-cmd-and-bat-files-t2551124.html
> http://windowsxp.mvps.org/slowrightclick.htm
> http://www.nirsoft.net/utils/shexview.html
>
>



--=20
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Installer works at our end without any issue.

I remember we had considered using "%COMSPEC% /c" earlier but dropped it
because command windows opens up for every new file execution.

On Fri, Jan 27, 2012 at 3:40 PM, Dave Page <dpage@pgadmin.org> wrote:

> iirc, using %COMSPEC% /c will cause the scripts to run in a visible
> command window, which is pretty ugly, and doesn't seem to be necessary
> anywhere except on your machine!
>
> What's the output from the "set" command on that box?
>
> On Thu, Jan 26, 2012 at 6:54 PM, Eric Borts <eborts@bltek.com> wrote:
> > Also, here is a link to the same issue on StackOverflow:
> >
> http://stackoverflow.com/questions/3559719/wscript-shell-run-doesnt-work-consistently
> >
> > Also solved using %COMSPEC% /c, though it doesn't say why this is a
> problem.
> >
> > Cheers,
> > Eric
> >
> >
> > On 1/26/2012 11:37 AM, Eric Borts wrote:
> >
> > On 1/26/2012 1:17 AM, Dave Page wrote:
> >
> > Dharmendra, can you look into this please?
> >
> > Eric, is there anything unusual about the configuration of your
> > machine? Suffice it to say, this doesn't normally happen.
> >
> > Hi Dave, I'm guessing the answer to that question is "yes". The machine
> came
> > preinstalled with Norton Internet Security, but this was turned off when
> I
> > ran the install. After further investigation to the .bat file, I realized
> > that I am also missing the "Edit" option when I right click a batch file.
> >
> > I investigated, uninstalled stuff, disabled a lot of stuff in my
> registry,
> > and nearly bricked my computer. After three hours, I'm going to have to
> ask
> > for suggestions. Here's what I found/tried:
> >
> > 1. uninstalled Norton Internet Security (and rebooted)
> > 2. uninstalled Acrobat Reader
> > 3. disabled all ContextMenuHandlers by
> >     a. renaming HKCR/*/shellex to oldshellex
> >     b. renaming HKCR/AllFileSystemsObjects/shellex to oldshellex
> >     c. tried, but was unable to rename HKCR/batfile/ShellEx, so renamed
> > HKCR/batfile/ShellEx/ContextMenuHandlers to oldContextMenuHandlers
> > 4. disabled all non-Microsoft shell extensions using ShellExView
> > 5. rebooted - computer bricked (black screen when Windows should be
> loading)
> > 6. booted in safe mode
> > 7. tested script (from my original response) and right click.
> >     a. no Edit option in batch file context menu
> >     b. script hung as before
> > 8. Undid steps 3 and 4 in safe mode
> > 9. Rebooted - booted into windows properly
> > 10. Still no Edit in context menu and script still hangs
> >
> > I'm open to suggestions. I think it might be related to Edit menu missing
> > from my batch file, as this is the only odd thing that I can tell about
> my
> > machine. I have another similar machine (earlier model Vaio) that both
> has
> > the Edit menu and runs the test script successfully. I compared the
> > HKCR/batfile registry trees (using TortoiseSVN diff) and they are
> identical.
> > Short of comparing the entire registry I'm at a loss.
> >
> > Would it be too dangerous to use WScript.Shell.Exec or to use
> > WScript.Shell.Run "%COMPSEC% /c" ? This has been an 11 hour struggle for
> me
> > so far, and I know at least a few others have had this same problem.
> Here is
> > a link to my work around on enterprisedb.
> >
> > Thanks,
> > Eric
> >
> > Reference Links:
> >
> http://www.pcreview.co.uk/forums/edit-print-open-missing-shell-context-menu-cmd-and-bat-files-t2551124.html
> > http://windowsxp.mvps.org/slowrightclick.htm
> > http://www.nirsoft.net/utils/shexview.html
> >
> >
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



--
Dharmendra Goyal
Senior Software Engineer
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: +91-20-30589493
Mobile: +91-9552103323

Website: http://www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.

Hi Dave and Dharmendra,

It is not the "%COMSPEC% /c" call that causes the window to popup, but the WindowStyle parameter to WShell.Run (see Table 3.9 in MS TechNet WSH Objects / Running Programs). Setting WindowStyle to "0" creates a hidden window. This is how the code in the installer is currently written. Setting it to "1" creates a visible window. This happens when using "%COMSPEC% /c" or when calling the batch file directly.

Here is a another site recommending the use of "%COMSPEC% /c" with a "0" second parameter, along with a note about the window (in)visibility:

    "[...] do not run any command that raises a prompt, dialog, msgbox or any other GUI. This [...] could hang your entire system (since the invisible GUI will be waiting for a reply [...]"

Test code is attached that demonstrates using COMSPEC with a "0" versus a "1".

Output from SET command is also attached. Note that I've verified that this problem still occurs in Safe Mode.

Any other suggestions? I've also posted to StackOverflow for adivce.

A separate line of reasoning for using COMSPEC is that the calling of the .bat directly assumes that default action is to execute the batch file. If a user has modified their default .bat actions (which I have not), the postgres installer will fail. Using COMSPEC will avoid that pitfall.

I'll keep you posted if I discover why my machine doesn't execute batch files by default, or how it ended up in this condition. The computer is only about 2 months old, so I haven't had *that* much time to overwhelm it with installs.

Eric




On 1/27/2012 3:15 AM, Dharmendra Goyal wrote:

Installer works at our end without any issue. 

I remember we had considered using "%COMSPEC% /c" earlier but dropped it because command windows opens up for every new file execution.

On Fri, Jan 27, 2012 at 3:40 PM, Dave Page <dpage@pgadmin.org> wrote:

iirc, using %COMSPEC% /c will cause the scripts to run in a visible
command window, which is pretty ugly, and doesn't seem to be necessary
anywhere except on your machine!

What's the output from the "set" command on that box?

On Thu, Jan 26, 2012 at 6:54 PM, Eric Borts <eborts@bltek.com> wrote:
> Also, here is a link to the same issue on StackOverflow:
> http://stackoverflow.com/questions/3559719/wscript-shell-run-doesnt-work-consistently
>
> Also solved using %COMSPEC% /c, though it doesn't say why this is a problem.
>
> Cheers,
> Eric
>
>
> On 1/26/2012 11:37 AM, Eric Borts wrote:
>
> On 1/26/2012 1:17 AM, Dave Page wrote:
>
> Dharmendra, can you look into this please?
>
> Eric, is there anything unusual about the configuration of your
> machine? Suffice it to say, this doesn't normally happen.
>
> Hi Dave, I'm guessing the answer to that question is "yes". The machine came
> preinstalled with Norton Internet Security, but this was turned off when I
> ran the install. After further investigation to the .bat file, I realized
> that I am also missing the "Edit" option when I right click a batch file.
>
> I investigated, uninstalled stuff, disabled a lot of stuff in my registry,
> and nearly bricked my computer. After three hours, I'm going to have to ask
> for suggestions. Here's what I found/tried:
>
> 1. uninstalled Norton Internet Security (and rebooted)
> 2. uninstalled Acrobat Reader
> 3. disabled all ContextMenuHandlers by
>     a. renaming HKCR/*/shellex to oldshellex
>     b. renaming HKCR/AllFileSystemsObjects/shellex to oldshellex
>     c. tried, but was unable to rename HKCR/batfile/ShellEx, so renamed
> HKCR/batfile/ShellEx/ContextMenuHandlers to oldContextMenuHandlers
> 4. disabled all non-Microsoft shell extensions using ShellExView
> 5. rebooted - computer bricked (black screen when Windows should be loading)
> 6. booted in safe mode
> 7. tested script (from my original response) and right click.
>     a. no Edit option in batch file context menu
>     b. script hung as before
> 8. Undid steps 3 and 4 in safe mode
> 9. Rebooted - booted into windows properly
> 10. Still no Edit in context menu and script still hangs
>
> I'm open to suggestions. I think it might be related to Edit menu missing
> from my batch file, as this is the only odd thing that I can tell about my
> machine. I have another similar machine (earlier model Vaio) that both has
> the Edit menu and runs the test script successfully. I compared the
> HKCR/batfile registry trees (using TortoiseSVN diff) and they are identical.
> Short of comparing the entire registry I'm at a loss.
>
> Would it be too dangerous to use WScript.Shell.Exec or to use
> WScript.Shell.Run "%COMPSEC% /c" ? This has been an 11 hour struggle for me
> so far, and I know at least a few others have had this same problem. Here is
> a link to my work around on enterprisedb.
>
> Thanks,
> Eric
>
> Reference Links:
> http://www.pcreview.co.uk/forums/edit-print-open-missing-shell-context-menu-cmd-and-bat-files-t2551124.html
> http://windowsxp.mvps.org/slowrightclick.htm
> http://www.nirsoft.net/utils/shexview.html
>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Dharmendra Goyal
Senior Software Engineer
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: +91-20-30589493
Mobile: +91-9552103323

Website: http://www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.

Regarding my final point:

"Similarly, you may prefer to have the default action for a batch file
(.bat) changed to Edit instead of Open. Double-clicking the file will
not run the commands in the file, and if users want to run the file,
they can use the*Open*command on the shortcut menu."
http://support.microsoft.com/kb/320036

This advice would be likely to hang the PostgreSQL installer.

Cheers,
Eric


On 1/27/2012 12:32 PM, Eric Borts wrote:
> Hi Dave and Dharmendra,
>
> It is not the "%COMSPEC% /c" call that causes the window to popup, but
> the WindowStyle parameter to WShell.Run (see Table 3.9 in MS TechNet
> WSH Objects / Running Programs
> <http://technet.microsoft.com/en-us/library/ee156605.aspx>). Setting
> WindowStyle to "0" creates a hidden window. This is how the code in
> the installer is currently written. Setting it to "1" creates a
> visible window. This happens when using "%COMSPEC% /c" or when calling
> the batch file directly.
>
> Here is a another site recommending
> <http://classicasp.aspfaq.com/general/how-do-i-execute-a-dos-command/batch-file/exe-from-asp.html>
> the use of "%COMSPEC% /c" with a "0" second parameter, along with a
> note about the window (in)visibility:
>
>     "[...] do not run any command that raises a prompt, dialog, msgbox
> or any other GUI. This [...] could hang your entire system (since the
> invisible GUI will be waiting for a reply [...]"
>
> Test code is attached that demonstrates using COMSPEC with a "0"
> versus a "1".
>
> Output from SET command is also attached. Note that I've verified that
> this problem still occurs in Safe Mode.
>
> Any other suggestions? I've also posted to StackOverflow
> <http://stackoverflow.com/questions/9038927/vbscript-hangs-when-launching-batch-file-with-wshell-script-run>
> for adivce.
>
> A separate line of reasoning for using COMSPEC is that the calling of
> the .bat directly assumes that default action is to execute the batch
> file. If a user has modified their default .bat actions (which I have
> not), the postgres installer will fail. Using COMSPEC will avoid that
> pitfall.
>
> I'll keep you posted if I discover why my machine doesn't execute
> batch files by default, or how it ended up in this condition. The
> computer is only about 2 months old, so I haven't had *that* much time
> to overwhelm it with installs.
>
> Eric

The installation now runs successfully after deleting that registry key.

In addition, I tried changing the default action on batch files from
"Open" to "Edit" using the registry (Windows 7). Double-clicking a file
opens it in Notepad, but the installation runs successfully. So it looks
like the UserChoice registry key, however it got there, is the essence
of the problem.

Which, of course, %COMSPEC% /c would avoid because the program handling
batch files is explicit.

Thanks,
Eric

On 1/27/2012 1:16 PM, Eric Borts wrote:
> I found the problem with my computer here
> <http://help.lockergnome.com/windows/BAT-File-Association-Broken--ftopict514456.html>.
> It turns out this registry entry was causing my problem:
>
> HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat
>     \UserChoice
>         Progid REG_SZ (Applications\cmd.exe)
>
> Deleting the \UserChoice key restored my context menu and ability to
> run a ".bat" directly instead of using %COMSPEC%.
>
> I am going to un-install an re-install postgres to verify that this
> solves my installation issues.
>
> Eric
>
>
>
>
>
>
>
> On 1/27/2012 12:41 PM, Eric Borts wrote:
>> Regarding my final point:
>>
>> "Similarly, you may prefer to have the default action for a batch
>> file (.bat) changed to Edit instead of Open. Double-clicking the file
>> will not run the commands in the file, and if users want to run the
>> file, they can use the*Open*command on the shortcut menu."
>> http://support.microsoft.com/kb/320036
>>
>> This advice would be likely to hang the PostgreSQL installer.
>>
>> Cheers,
>> Eric
>>
>>
>> On 1/27/2012 12:32 PM, Eric Borts wrote:
>>> Hi Dave and Dharmendra,
>>>
>>> It is not the "%COMSPEC% /c" call that causes the window to popup,
>>> but the WindowStyle parameter to WShell.Run (see Table 3.9 in MS
>>> TechNet WSH Objects / Running Programs
>>> <http://technet.microsoft.com/en-us/library/ee156605.aspx>). Setting
>>> WindowStyle to "0" creates a hidden window. This is how the code in
>>> the installer is currently written. Setting it to "1" creates a
>>> visible window. This happens when using "%COMSPEC% /c" or when
>>> calling the batch file directly.
>>>
>>> Here is a another site recommending
>>> <http://classicasp.aspfaq.com/general/how-do-i-execute-a-dos-command/batch-file/exe-from-asp.html>
>>> the use of "%COMSPEC% /c" with a "0" second parameter, along with a
>>> note about the window (in)visibility:
>>>
>>>     "[...] do not run any command that raises a prompt, dialog,
>>> msgbox or any other GUI. This [...] could hang your entire system
>>> (since the invisible GUI will be waiting for a reply [...]"
>>>
>>> Test code is attached that demonstrates using COMSPEC with a "0"
>>> versus a "1".
>>>
>>> Output from SET command is also attached. Note that I've verified
>>> that this problem still occurs in Safe Mode.
>>>
>>> Any other suggestions? I've also posted to StackOverflow
>>> <http://stackoverflow.com/questions/9038927/vbscript-hangs-when-launching-batch-file-with-wshell-script-run>
>>> for adivce.
>>>
>>> A separate line of reasoning for using COMSPEC is that the calling
>>> of the .bat directly assumes that default action is to execute the
>>> batch file. If a user has modified their default .bat actions (which
>>> I have not), the postgres installer will fail. Using COMSPEC will
>>> avoid that pitfall.
>>>
>>> I'll keep you posted if I discover why my machine doesn't execute
>>> batch files by default, or how it ended up in this condition. The
>>> computer is only about 2 months old, so I haven't had *that* much
>>> time to overwhelm it with installs.
>>>
>>> Eric
>>
>

I found the problem with my computer here
<http://help.lockergnome.com/windows/BAT-File-Association-Broken--ftopict514456.html>.
It turns out this registry entry was causing my problem:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat
     \UserChoice
         Progid REG_SZ (Applications\cmd.exe)

Deleting the \UserChoice key restored my context menu and ability to run
a ".bat" directly instead of using %COMSPEC%.

I am going to un-install an re-install postgres to verify that this
solves my installation issues.

Eric







On 1/27/2012 12:41 PM, Eric Borts wrote:
> Regarding my final point:
>
> "Similarly, you may prefer to have the default action for a batch file
> (.bat) changed to Edit instead of Open. Double-clicking the file will
> not run the commands in the file, and if users want to run the file,
> they can use the*Open*command on the shortcut menu."
> http://support.microsoft.com/kb/320036
>
> This advice would be likely to hang the PostgreSQL installer.
>
> Cheers,
> Eric
>
>
> On 1/27/2012 12:32 PM, Eric Borts wrote:
>> Hi Dave and Dharmendra,
>>
>> It is not the "%COMSPEC% /c" call that causes the window to popup,
>> but the WindowStyle parameter to WShell.Run (see Table 3.9 in MS
>> TechNet WSH Objects / Running Programs
>> <http://technet.microsoft.com/en-us/library/ee156605.aspx>). Setting
>> WindowStyle to "0" creates a hidden window. This is how the code in
>> the installer is currently written. Setting it to "1" creates a
>> visible window. This happens when using "%COMSPEC% /c" or when
>> calling the batch file directly.
>>
>> Here is a another site recommending
>> <http://classicasp.aspfaq.com/general/how-do-i-execute-a-dos-command/batch-file/exe-from-asp.html>
>> the use of "%COMSPEC% /c" with a "0" second parameter, along with a
>> note about the window (in)visibility:
>>
>>     "[...] do not run any command that raises a prompt, dialog,
>> msgbox or any other GUI. This [...] could hang your entire system
>> (since the invisible GUI will be waiting for a reply [...]"
>>
>> Test code is attached that demonstrates using COMSPEC with a "0"
>> versus a "1".
>>
>> Output from SET command is also attached. Note that I've verified
>> that this problem still occurs in Safe Mode.
>>
>> Any other suggestions? I've also posted to StackOverflow
>> <http://stackoverflow.com/questions/9038927/vbscript-hangs-when-launching-batch-file-with-wshell-script-run>
>> for adivce.
>>
>> A separate line of reasoning for using COMSPEC is that the calling of
>> the .bat directly assumes that default action is to execute the batch
>> file. If a user has modified their default .bat actions (which I have
>> not), the postgres installer will fail. Using COMSPEC will avoid that
>> pitfall.
>>
>> I'll keep you posted if I discover why my machine doesn't execute
>> batch files by default, or how it ended up in this condition. The
>> computer is only about 2 months old, so I haven't had *that* much
>> time to overwhelm it with installs.
>>
>> Eric
>

On Sat, Jan 28, 2012 at 2:17 AM, Eric Borts <eborts@bltek.com> wrote:

>  The installation now runs successfully after deleting that registry key.
>
> In addition, I tried changing the default action on batch files from
> "Open" to "Edit" using the registry (Windows 7). Double-clicking a file
> opens it in Notepad, but the installation runs successfully. So it looks
> like the UserChoice registry key, however it got there, is the essence of
> the problem.
>
> Which, of course, %COMSPEC% /c would avoid because the program handling
> batch files is explicit.
>
Nice analysis Eric. ANy idea why (which program set this) this particular
registry was set.

Dave, shall we consider using "%COMSPEC% /c" with 0 as second parameter..??

>
> Thanks,
> Eric
>
>
> On 1/27/2012 1:16 PM, Eric Borts wrote:
>
> I found the problem with my computer
here<http://help.lockergnome.com/windows/BAT-File-Association-Broken--ftopict514456.html>.
> It turns out this registry entry was causing my problem:
>
> HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat
>     \UserChoice
>         Progid REG_SZ (Applications\cmd.exe)
>
> Deleting the \UserChoice key restored my context menu and ability to run a
> ".bat" directly instead of using %COMSPEC%.
>
> I am going to un-install an re-install postgres to verify that this solves
> my installation issues.
>
> Eric
>
>
>
>
>
>
>
> On 1/27/2012 12:41 PM, Eric Borts wrote:
>
> Regarding my final point:
>
> "Similarly, you may prefer to have the default action for a batch file
> (.bat) changed to Edit instead of Open. Double-clicking the file will not
> run the commands in the file, and if users want to run the file, they can
> use the *Open* command on the shortcut menu."
> http://support.microsoft.com/kb/320036
>
> This advice would be likely to hang the PostgreSQL installer.
>
> Cheers,
> Eric
>
>
> On 1/27/2012 12:32 PM, Eric Borts wrote:
>
> Hi Dave and Dharmendra,
>
> It is not the "%COMSPEC% /c" call that causes the window to popup, but the
> WindowStyle parameter to WShell.Run (see Table 3.9 in MS TechNet WSH
> Objects / Running Programs<http://technet.microsoft.com/en-us/library/ee156605.aspx>).
> Setting WindowStyle to "0" creates a hidden window. This is how the code in
> the installer is currently written. Setting it to "1" creates a visible
> window. This happens when using "%COMSPEC% /c" or when calling the batch
> file directly.
>
> Here is a another site
recommending<http://classicasp.aspfaq.com/general/how-do-i-execute-a-dos-command/batch-file/exe-from-asp.html>theuse of
"%COMSPEC%/c" with a "0" second parameter, along with a note 
> about the window (in)visibility:
>
>     "[...] do not run any command that raises a prompt, dialog, msgbox or
> any other GUI. This [...] could hang your entire system (since the
> invisible GUI will be waiting for a reply [...]"
>
> Test code is attached that demonstrates using COMSPEC with a "0" versus a
> "1".
>
> Output from SET command is also attached. Note that I've verified that
> this problem still occurs in Safe Mode.
>
> Any other suggestions? I've also posted to
StackOverflow<http://stackoverflow.com/questions/9038927/vbscript-hangs-when-launching-batch-file-with-wshell-script-run>for
adivce.
>
> A separate line of reasoning for using COMSPEC is that the calling of the
> .bat directly assumes that default action is to execute the batch file. If
> a user has modified their default .bat actions (which I have not), the
> postgres installer will fail. Using COMSPEC will avoid that pitfall.
>
> I'll keep you posted if I discover why my machine doesn't execute batch
> files by default, or how it ended up in this condition. The computer is
> only about 2 months old, so I haven't had *that* much time to overwhelm it
> with installs.
>
> Eric
>
>
>
>
>


--
Dharmendra Goyal
Senior Software Engineer
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: +91-20-30589493
Mobile: +91-9552103323

Website: http://www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.

On 1/27/2012 7:47 PM, Dharmendra Goyal wrote:
> Nice analysis Eric. ANy idea why (which program set this) this
> particular registry was set.
Thanks Dharmendra! It was pretty exhausting.

I haven't a clue how this got changed. I tried goofing around with
shift, ctrl, etc. and I wasn't even able to get an "Open With" option on
the context menu. The only way I found to re-associate the file was:

     Control Panel > All Control Panel Items > Default Programs > Set
Associations
     Double click .bat
     Click Browse
     Browse to C:\windows\system32\cmd.exe
     Click Open
     Select "Virtual Command Shell 9014006604090000"
     Click OK

So I doubt I did it manually. As far as what program made that
modification or what steps I went through to get Windows to give me the
option to re-associate a batch file, I don't know.

Now, once the association is set, it's impossible to remove without
editing the registry.

Thanks for spurring me on to find the source of the problem!
E

For kicks, here are a few links where people set the association
manually and were advised to delete the .bat\UserChoice key:
http://social.technet.microsoft.com/Forums/en/w7itprogeneral/thread/fc2ca91d-5509-4c9b-92a5-5af19375e361
http://www.computing.net/answers/windows-7/how-to-disassociate-batch-files-from-notepad/5521.html

On Sat, Jan 28, 2012 at 2:47 AM, Dharmendra Goyal
<dharmendra.goyal@enterprisedb.com> wrote:
>
>
> On Sat, Jan 28, 2012 at 2:17 AM, Eric Borts <eborts@bltek.com> wrote:
>>
>> The installation now runs successfully after deleting that registry key.
>>
>> In addition, I tried changing the default action on batch files from
>> "Open" to "Edit" using the registry (Windows 7). Double-clicking a file
>> opens it in Notepad, but the installation runs successfully. So it looks
>> like the UserChoice registry key, however it got there, is the essence of
>> the problem.
>>
>> Which, of course, %COMSPEC% /c would avoid because the program handling
>> batch files is explicit.
>
> Nice analysis Eric. ANy idea why (which program set this) this particular
> registry was set.
>
> Dave, shall we consider using "%COMSPEC% /c" with 0 as second parameter..??

We can certainly try it, though I'm concerned it may break more
systems than it fixes, eg. those where %COMSPEC% has been
intentionally changed because the use wants to use a different shell.


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jan 30, 2012 at 7:49 AM, Eric Borts <eborts@bltek.com> wrote:
> On 1/29/2012 3:02 AM, Dave Page wrote:
>>
>> On Sat, Jan 28, 2012 at 2:47 AM, Dharmendra Goyal
>> <dharmendra.goyal@enterprisedb.com> =A0wrote:
>>>
>>>
>>> Nice analysis Eric. ANy idea why (which program set this) this particul=
ar
>>> registry was set.
>>>
>>> Dave, shall we consider using "%COMSPEC% /c" with 0 as second
>>> parameter..??
>>
>> We can certainly try it, though I'm concerned it may break more
>> systems than it fixes, eg. those where %COMSPEC% has been
>> intentionally changed because the use wants to use a different shell.
>>
>>
> I'd have to agree with Dave here. It was clearly a problem with my batch
> file association. I don't know *how* I got into this state, but at least
> there's a good log now of how to fix the problem for users that have the
> same problem!
>
> I suppose you could detect the problem and issue warning by running a test
> echo batch file and *not waiting* on the result, then pausing for a secon=
d,
> and checking to see if the output file was created. Heck or check the
> registry to see if there's a UserChoice key on the .bat extension.
>
> In any case, I'm satisfied that my computer was messed up and it's now
> fixed. And I've got my context menu back!

That's the most important thing! Thanks for the hard work and
excellent analysis of the problem.

Regards, Dave.

--=20
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 1/29/2012 3:02 AM, Dave Page wrote:
> On Sat, Jan 28, 2012 at 2:47 AM, Dharmendra Goyal
> <dharmendra.goyal@enterprisedb.com>  wrote:
>>
>> Nice analysis Eric. ANy idea why (which program set this) this particular
>> registry was set.
>>
>> Dave, shall we consider using "%COMSPEC% /c" with 0 as second parameter..??
> We can certainly try it, though I'm concerned it may break more
> systems than it fixes, eg. those where %COMSPEC% has been
> intentionally changed because the use wants to use a different shell.
>
>
I'd have to agree with Dave here. It was clearly a problem with my batch
file association. I don't know *how* I got into this state, but at least
there's a good log now of how to fix the problem for users that have the
same problem!

I suppose you could detect the problem and issue warning by running a
test echo batch file and *not waiting* on the result, then pausing for a
second, and checking to see if the output file was created. Heck or
check the registry to see if there's a UserChoice key on the .bat
extension.

In any case, I'm satisfied that my computer was messed up and it's now
fixed. And I've got my context menu back!

Thanks,
Eric