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

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&gt;
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&gt;.

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

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

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
<http://technet.microsoft.com/en-us/library/ee156605.aspx&gt;). 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&gt;
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&gt;
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

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

I found the problem with my computer here
<http://help.lockergnome.com/windows/BAT-File-Association-Broken--ftopict514456.html&gt;.
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

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 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&gt;.
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&gt;).
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&gt;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&gt;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 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

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>  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!

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

Regards, Dave.

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

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