Comspec Oddies with cmd and quicken 2008

[clido01]

I have accidentally discovered a 'fix' for a *very* annoying problem with quicken 2008 r4 thru r7 that *apparently* has to do with some oddity of CMD that quicken is relying upon to complete on-line program updates starting at Release/patch 4 and continuing to the current patch level 7 *and* which confused 4NT when using it as the comspec value. This problem evaded *extensive* quicken resolution including manual updates and even going so far as messing up a machine so badly it caused a windows re-activation. I had finally given up on updating the program for the last 3 releases/patches because of that. I was running an earlier version of 4NT (7.01) and had to upgrade it to v8.01 and finally to v9.02 due to another unrelated issue, but in the course of doing that I decided to try again to update Quicken as it appeared it might have a new process to update again. Upon trying it, it 'hung' and had to be killed like all the previous patches from v3-4 up to v7. However, I happened to notice a 2nd 4NT prompt in the toolbar/processbar after installing TCC/4NTv9.02. When I clicked on it to bring it up, it appeared it had been invoked by the quicken update process and remained visible with 4NTv9 that did not happen with 4NTv7. I examined the window and it said 'invalid command' or something of that nature and then the command (or portion it tried to execute): "CON". It did not have anymore diagnostics that I could find. I killed the processes and redid the test and the quicken update hung again and the 2nd instance of 4NT was again on the toolbar with the same message. Since I had updated the comspec with the new 4NTv9 location, on a hunch I changed comspec back to the CMD and retried the quicken updated *and it worked*... :D after many months of trial/support/update from quicken.
. This problem exists on 2 windows XP machines and reacted in exactly the same way, but I never connected it in any way with the comspec setting.
Here's the scenario and more specifics if interested:
Windows XP Professional SP2 with all latest MS updates.
Original 4NT ver: 7.01
Original comspec: c:\4nt\4nt.exe
New 4NT ver:9.02
New comspec: c:\tcmd\v9x\4nt.exe
Quicken version: 2008 Home and Business patch/release/v4
This finally showed a quicken failure in the 4NT window that was started by the update process which had never appeared with the earlier 4NT version.
After setting
comspec=C:\WINDOWS\system32\cmd.exe
the quicken process passed the point it had hung previously and completed the upgrade to v7 without issue.

The other Windows XP Professional is SP3 and has the same Quicken 'hanging' issue but has not had the 4NT version updated yet, so it is still running v7.01. If this is not 'coincidental' and indeed solves the problem again, is there some other piece of diagnostic info that I could provide or get before I update/upgrade it. It is possible it won't have exactly the same symptoms I suppose, but I only get 1 shot at it...;) if it succeeds again.

I've used 4DOS/4NT for so many years, I wanted to take the time to post this in the ever so unlikely case that it might help someone else also if they happen to use this combination/version and if I could help with more info on the 2nd machine if it duplicates the problem.

Doug

 

[samintz]

Doug,

I recommend downloading a copy of Process Explorer from SysInternals
(http://www.sysinternals.com) and turning on the display of the command
line. You can see every process running on your PC plus a whole lot of
very useful diagnostic information like the command line used to invoke
the process. Knowing what the command line is that Quicken is using will
go a long way toward helping to diagnose the problem.

-Scott

clido01 <> wrote on 07/13/2008 06:19:27 PM:

> I have accidentally discovered a 'fix' for a *very* annoying problem
> with quicken 2008 r4 thru r7 that *apparently* has to do with some
> oddity of CMD that quicken is relying upon to complete on-line
> program updates starting at Release/patch 4 and continuing to the
> current patch level 7 *and* which confused 4NT when using it as the
> comspec value. This problem evaded *extensive* quicken resolution
> including manual updates and even going so far as messing up a
> machine so badly it caused a windows re-activation. I had finally
> given up on updating the program for the last 3 releases/patches
> because of that. I was running an earlier version of 4NT (7.01) and
> had to upgrade it to v8.01 and finally to v9.02 due to another
> unrelated issue, but in the course of doing that I decided to try
> again to update Quicken as it appeared it might have a new process
> to update again. Upon trying it, it 'hung' and had to be killed like
> all the previous patches from v3-4 ! up to v7. However, I happened
> to notice a 2nd 4NT prompt in the toolbar/processbar after
> installing TCC/4NTv9.02. When I clicked on it to bring it up, it
> appeared it had been invoked by the quicken update process and
> remained visible with 4NTv9 that did not happen with 4NTv7. I
> examined the window and it said 'invalid command' or something of
> that nature and then the command (or portion it tried to execute):
> "CON". It did not have anymore diagnostics that I could find. I
> killed the processes and redid the test and the quicken update hung
> again and the 2nd instance of 4NT was again on the toolbar with the
> same message. Since I had updated the comspec with the new 4NTv9
> location, on a hunch I changed comspec back to the CMD and retried
> the quicken updated *and it worked*... [image removed] after many
> months of trial/support/update from quicken.
> . This problem exists on 2 windows XP machines and reacted in
> exactly the same way, but I never connected it in any way with the
> comspec setting.
> Here's the scenario and more specifics if interested:
> Windows XP Professional SP2 with all latest MS updates.
> Original 4NT ver: 7.01
> Original comspec: c:\4nt\4nt.exe
> New 4NT ver:9.02
> New comspec: c:\tcmd\v9x\4nt.exe
> Quicken version: 2008 Home and Business patch/release/v4
> This finally showed a quicken failure in the 4NT window that was
> started by the update process which had never appeared with the
> earlier 4NT version.
> After setting
> comspec=C:\WINDOWS\system32\cmd.exe
> the quicken process passed the point it had hung previously and
> completed the upgrade to v7 without issue.
>
> The other Windows XP Professional is SP3 and has the same Quicken
> 'hanging' issue but has not had the 4NT version updated yet, so it
> is still running v7.01. If this is not 'coincidental' and indeed
> solves the problem again, is there some other piece of diagnostic
> info that I could provide or get before I update/upgrade it. It is
> possible it won't have exactly the same symptoms I suppose, but I
> only get 1 shot at it...[image removed] if it succeeds again.
>
> I've used 4DOS/4NT for so many years, I wanted to take the time to
> post this in the ever so unlikely case that it might help someone
> else also if they happen to use this combination/version and if I
> could help with more info on the 2nd machine if it duplicates the

problem.

>
> Doug
>
>

 

[Charles Dye]

I recommend downloading a copy of Process Explorer from SysInternals (http://www.sysinternals.com) and turning on the display of the command line. You can see every process running on your PC plus a whole lot of very useful diagnostic information like the command line used to invoke the process. Knowing what the command line is that Quicken is using will go a long way toward helping to diagnose the problem.

Or just stick a DEBUG=3 line in the .INI file.

 

[clido01]

Or just stick a DEBUG=3 line in the .INI file.

Thanks for the suggestions all. I'll try to see what I can capture when I get it set up.

Doug

 

[clido01]

Thanks for the suggestions all. I'll try to see what I can capture when I get it set up.

Doug

I finally got V9x installed and was able to set the debug=3 and here is the offending command:
TCC tail is: [C:\TCMD\v9x\4nt.exe CON /C awuninst.bat]
Press any key to continue ...

It's the CON in the command that Microsoft's cmd.exe 'overlooks' I assume and which 4nt sees as an error. The quicken update hung as usual due to this too and will be corrected by going back to cmd.exe as the comspec value I suspect. I will update later if it doesn't succeed in performing the update, but with my manual testing with cmd.exe, it seems to ignore the CON portion of the command.
Anyway, thanks to all for the help in seeing what is/was going on.

Doug

 

[rconn]

clido01 wrote:

>
> Quote:
> I finally got V9x installed and was able to set the debug=3 and here is
> the offending command:
> TCC tail is: [C:\TCMD\v9x\4nt.exe CON /C awuninst.bat]
> Press any key to continue ...
>
> It's the CON in the command that Microsoft's cmd.exe 'overlooks' I
> assume and which 4nt sees as an error. The quicken update hung as usual
> due to this too and will be corrected by going back to cmd.exe as the
> comspec value I suspect. I will update later if it doesn't succeed in
> performing the update, but with my manual testing with cmd.exe, it seems
> to ignore the CON portion of the command.
> Anyway, thanks to all for the help in seeing what is/was going on.

This is undocumented CMD behavior (if the first arg is a device, the i/o
is redirected there). But in this case, it's dumb syntax, since the
console is going to be using CON by default.

I've made a change for the next build to detect (and ignore) the useless
CON.

Rex Conn
JP Software