-
1 Attachment(s)
RUN issues (again)
Friedrich
Some time ago we had some conversation regarding my unhappiness with error
reporting re. the Run command.. and deciding whether to use the default
operation, or set to use ShellExecute.
Despite a couple of others advising to use ShellExecute, you were adamant
that you did not normally use it in your installations, and also cited that
it allowed less control over execution.
I was swayed by this, and reverted from my position of using ShelExecute,
back to the default.
Unfortunately this now appears to have been a big mistake - we are now
(tonight) distributing my latest upgrade, and are already getting reports
from several stores regarding Run issues - all with the same result!!!
The attached (faxed in by a helpful store) shows this repeating error - no
idea what the numbers mean (which was the source of my complaint last time)
Seems there is 'something going on' with the default Run call on a number
of computers 'out there' in the shops.
I shall be reverting to the use of ShelExecute, to see if I can salvage some
of these upgrade installations. But my advice to users setting up for major
distributions now is to be suspicious of using the default Run call, and to
use ShellExecute on Running
external programs.
Just my (NS)HO, of course
It looks like we are in for a long night....
HTH
Steve
-
Re: RUN issues (again)
Steve,
> Some time ago we had some conversation regarding my unhappiness with error
> reporting re.
Because your were unhappy with the error reporting, we changed error
handling for "Run Program" and give you access to the Windows return codes
now.
But you did not mention which build you are using. Make sure you have
#2537.
I also have no idea what your return number means. If %_SB_RETURNEX%
returns 0 (that means GetLastError returned 0) and %_SB_ERRORCODE% returns a
value (and the "Wait" option is enabled) then this value comes from
GetExitCodeProcess - in other words, from the executed application itself.
Hope this helps.
--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910
SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes
-- Official Comodo Code Signing and SSL Certificate Partner
-
Re: RUN issues (again)
> But my advice to users setting up for major distributions now is to
> be suspicious of using the default Run call, and to use ShellExecute
> on Running external programs.
Just for the record - we are using ShellExecuteEx only when starting an
elevated application from a non-elevated install. For example, in the new
(non-elevated) wucheck.exe. Even the Web Update Client (wupdate.exe) does
*not* use ShellExecute -- it uses CreateProcess. And wupdate.exe is used on
quite a few million machines. We always use CreateProcess in our own
installations and all Script Writing Consulting projects.
--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910
SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes
-- Official Comodo Code Signing and SSL Certificate Partner
-
Re: RUN issues (again)
Steve,
Perhaps the following happens. FYI, error code -1073741511 (0xC0000139 in
32bit-hex) means:
---
#define STATUS_ENTRYPOINT_NOT_FOUND ((NTSTATUS)0xC0000139L)
The procedure entry point XX could not be located in the dynamic link
library XX.
---
So perhaps you call an .exe that calls a function in a DLL -- but that
function could not be found in a DLL. That's why your application
returns -1073741511 (IMO).
--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910
SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes
-- Official Comodo Code Signing and SSL Certificate Partner
-
1 Attachment(s)
Re: RUN issues (again)
Friedrich,
Oh yes, I already know that - found out the hard way, by tracking it down!
But wouldn't it have been nice if the installer TOLD ME that.... (I still
don't believe its 'that hard')
But at bare minimum there should be URL lookup references for error lists
(for example, where did you get that #define from?)
This is what I have asked for and will continue to ask for in SetupBuilder.
However, I must say that in this case I jumped the gun re. CreateProcess -
this was a 'valid' failure, not a machine-fussy one as I suspected.
So I retract that part - and Createprocess survives in the install script
Now, the real cause - for some unknown reason, SB has only installed 1 of
the 3 DLLs it was scripted to install... and thus the dependent child
process did indeed fail on Run.
I have no answer for why this failure has occurred on multiple machines.
All 3 DLLs weer handled in the same way (see attached) but only *1* has been
installed.
When I try to debug here it works 100%.... I'm stumped.
Steve Bywaters
-
Re: RUN issues (again)
Steve,
> But wouldn't it have been nice if the installer TOLD ME that.... (I still
> don't believe its 'that hard')
> But at bare minimum there should be URL lookup references for error lists
> (for example, where did you get that #define from?)
>
> This is what I have asked for and will continue to ask for in
> SetupBuilder.
WHAT???????? I have to admit that I am really "not amused" (AGAIN).
You tell us about mysterious error codes, that there are problems with the
default SetupBuilder "Run Program..." function, that you'll have a long
night because of an installer malfunction and that it appears to be a big
mistake you followed my advise to use the default Run option (which makes
use of CreateProcess).
Then on top of that, you make an advice to users setting up for "major
distributions" to be suspicious of using the default Run call.
And now it turns out that the mysterious error code was not mysterious at
all and that the very same default "Run Program..." function was smart
enough to provide you with detailed information about a fatal error in
YOUR OWN application. CreateProcess is very powerful and can get the
correct return value for such a scenario.
Please don't ask me again to provide a built-in SetupBuilder function
that converts return values (e.g. -1073741511) issued by YOUR OWN
application into a "human readable" error message. It's simply not
possible. I really hope this issue in your application tells you why
this is so. Or just let me know how to get the error description for
-1073741511 from the operating system. There are hundreds of 0xC0000000L
(and even thousands of other possible error codes). And then all the
return values you can pass back from the .exe to the installer or from
a DLL to the EXE and then to the installer.
You don't want to see -1073741511 again in the future? No problem.
Call the DLLs dynamically instead of statically from your application
and detect the entry point error. Then pass 12345 back to the installer
and display a "Sorry, entry point not found" message box. But then
there are all the other hundreds and thousands possible Windows error
codes (no human readable text available). So it will not really help.
Do you see what I mean????
And I really hope you did not tell all "the shops" that this error was
caused by a goddamned buggy SetupBuilder product, but a bug in your own
software.
Regards,
--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910
SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes
-- Official Comodo Code Signing and SSL Certificate Partner
-
Re: RUN issues (again)
>Please don't ask me again to provide a built-in SetupBuilder function
> that converts return values (e.g. -1073741511) issued by YOUR OWN
> application into a "human readable" error message. It's simply not
Nice spray - but not quite on point:.
1) When I run the Clarion program (that could not run) - it tells me
explicitly that the "entry point could not be located in the dynamic
library..."
Then in a following program (Clarion) I get a "error 47 - Invalid File
Declaration"
These are helpful error messages.... not just error codes!.
*HOWEVER*, in deference to you I already asked that at - a bare minimum
there should be a reference list of URLS of errorcodes to look up all this
myriad of codes that you mention..
I say again - it should not be necesary to do an extensive search to
decode -123456789 (or whatever)
2) The reason the program failed is because SB failed to install a required
DLL!
I'm still looking into this.. but its real, and so far has happened on 6
machines (But not in any of our testing)
> And I really hope you did not tell all "the shops" that this error was
> caused by a goddamned buggy SetupBuilder product, but a bug in your own
> software.
Your logic is faulty - this was not caused by any bug in *my* software.
See 2, above.
(Or.. if I use the same finger-pointing mode that you have: it failed
because the correct DLL was not installed by YOUR program!)
Steve
-
Re: RUN issues (again)
> 2) The reason the program failed is because SB failed to install a required
> DLL!
Steve,
AFAIK, there is only one circumstance in which SB would "fail to install" a
DLL on some machines vs others.
That would be if the DLL was "in use".
SB can not replace a file that is in use and it would queue the DLL
installation for completion after a reboot.
If your users do not reboot (or try to run the app without a reboot), then
the effect would be as if the DLL was not installed.
Charles
--
-------------------------------------------------------------------------------------------------------
Charles Edmonds
www.ezchangelog.com - "Free ChangeLog software to manage your projects!"
www.setupcast.com - "A revolutionary new publishing system for software
developers - enhanced for SetupBuilder users!"
www.pagesnip.com - "Print and Save the Web, just the way you want it!"
www.clarionproseries.com - "Serious imaging tools for Clarion Developers"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms!"
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------
-
Re: RUN issues (again)
> Nice spray - but not quite on point:.
>
>
> 1) When I run the Clarion program (that could not run) - it tells me
> explicitly that the "entry point could not be located in the dynamic
> library..."
> Then in a following program (Clarion) I get a "error 47 - Invalid File
> Declaration"
> These are helpful error messages.... not just error codes!.
Aha, very interesting. You obviously know what you are talking about.
Okay, let's prove it. We use a Clarion application to RUN() a simple
test.exe. This test.exe calls a "SteveIsCool" function located in test.dll.
Unfortunately, the "SteveIsCool" function does not exist in the test.dll
(entry point not found).
So you are telling us that you'll receive a helpful error message from
Clarion now. Right?
No, WRONG! The Clarion ERRORCODE() will return 300 and ERROR() will give
you "Unknown Error Posted: 300"
SetupBuilder gave you STATUS_ENTRYPOINT_NOT_FOUND ((NTSTATUS)0xC0000139L)
which means "The procedure entry point XX could not be located in the
dynamic link library XX."
So what are your thoughts on this?
--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910
SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes
-- Official Comodo Code Signing and SSL Certificate Partner
-
Re: RUN issues (again)
> (Or.. if I use the same finger-pointing mode that you have: it failed
> because the correct DLL was not installed by YOUR program!)
Yeah, of course.
But what about the following scenario. An installer has to replace "locked"
DLLs and a reboot is required in order to finish the installation. But a
smart programmer disabled the reboot procedure and starts a program that
depends on the new DLLs. The problem is, the new DLLs are not there because
Windows has to reboot the system to replace the locked DLL files.
--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910
SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes
-- Official Comodo Code Signing and SSL Certificate Partner