PDA

View Full Version : Call DLL-Problem on Vista



NewsArchive
04-14-2009, 01:57 AM
Hi,

the following code snippet schould change the "path" environment
variable for the current process. This can not be done by the SB "Edit
Environment variable" statement, so I have to call a Windows DLL. This
works fine on Win XP (32bit), but it crashes on Win Vista 64 bit.

Set Variable %PATH% to FUNCTION:Get System Info(Expand Environment
Variable) for "Path"
Set Variable %PATH% to "C:test\bin;%PATH%"
Display Message Box "Setze Pfad auf\n\n%PATH%\n" -- ""
Call DLL "%SYS32DIR%\kernel32.dll" -- Function "SetEnvironmentVariable"
(*STRING,*STRING) ("Path","%PATH%")
Set Variable %PATH% to FUNCTION:Get System Info(Expand Environment
Variable) for "Path"
Display Message Box "Überlebt. Pfad ist jetzt:\n\n%PATH%\n" -- ""


Could Can somebody help me?

Thanks.

Markus

NewsArchive
04-14-2009, 01:57 AM
Markus,

Your function prototype is incorrect. It should be STRING, STRING instead
of *STRING, *STRING.

I changed this in your project and it works fine on Vista Ultimate 64-bit.

Friedrich

NewsArchive
04-14-2009, 01:58 AM
Hi Friedrich,

I changed my script (attached), but it still crashes on Vista Home Basic
64 bit.

Markus

NewsArchive
04-14-2009, 01:58 AM
Hi Markus,

> I changed my script (attached), but it still crashes on Vista Home Basic
> 64 bit.

Just for fun, I executed your .exe on four completely different machines
running Vista 64-bit. No GPF at all.

Are you sure that the "Call DLL" crashes? Perhaps your PATH is > 1,024
bytes and "FUNCTION:Get System Info(Expand Environment Variable)" causes the
GPF?

Friedrich

NewsArchive
04-14-2009, 05:01 AM
Hi Friedrich,

I've changed my project a little bit to check wether the path length
causes the problem. Unfortunately, this is not the problem and yes, it
is the call DLL statement, that crahes. Look at the attached screenshots
and the changed project.

Markus

NewsArchive
04-14-2009, 05:03 AM
Hi Markus,

Unfortunately, we can't reproduce this on any of our 64-bit machines. Even
on XP x64, your project works fine. I have not opened a ticket because we
have not changed the "Call DLL" function for more than six years now and the
function is used in SetupBuilder installations on millions of machines. So
I assume, it's "machine specific".

I have recompiled your project with SB7 (see attached). Does this also
cause a GPF on your machine?

Friedrich

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

NewsArchive
04-14-2009, 05:04 AM
Yes, it does. I will do more tests and come back later.

Thank you for your support.

Markus

NewsArchive
04-14-2009, 05:04 AM
> Yes, it does. I will do more tests and come back later.
>
> Thank you for your support.

And this one? I think it has something to do with the size of the return
string.

www.lindersoft.com/projects/pathtest1.zip

Friedrich

NewsArchive
04-14-2009, 05:05 AM
This one works!

Markus Zander

NewsArchive
04-14-2009, 05:05 AM
>
> This one works!
>

Perfect. Then it's caused by the size of the return string. Changed in SB7
now (to 10K) and SB6 (to 1K).

Thanks for the report.

Friedrich

NewsArchive
04-14-2009, 05:06 AM
Hi Markus,

If the SB7 compiled project also GPF, please let me know and I'll send a new
one. There is a "pointer to argument" limit of 512 bytes in the CallDll
function. So it's possible that your 767-byte return string causes this.

Friedrich

NewsArchive
04-14-2009, 05:09 AM
Thank you, Friedrich. Great!

Can you tell me, when you will release SB7 RC? This is a showstopper for
me and prevents further testing on our "real world systems".

Markus

NewsArchive
04-14-2009, 05:10 AM
> Thank you, Friedrich. Great!
>
> Can you tell me, when you will release SB7 RC? This is a showstopper
> for me and prevents further testing on our "real world systems".

The next coming SB7 beta release will be the last beta before the "release
candidate". So we have to make sure that it works rock solid. We still
have to fix 8 open issues in the latest SB7 source codes.

We have increased the "Call Dll" argument size to 1K in our latest internal
SB6 source codes. Do you think this could be a temporary solution?

Friedrich

NewsArchive
04-14-2009, 05:10 AM
At least for the tests, this would be enough. Is it possible that I can
get this "internal build"?

Markus Zander

NewsArchive
04-15-2009, 01:33 AM
> At least for the tests, this would be enough. Is it possible that I can
> get this "internal build"?

You should receive an email later today.

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

NewsArchive
04-15-2009, 01:33 AM
Great, email received and it works! Thank you very much, Friedrich.

Markus

NewsArchive
04-15-2009, 01:34 AM
Hi Friedrich,

> Perfect. Then it's caused by the size of the return string. Changed in SB7
> now (to 10K) and SB6 (to 1K).

In what kind of circumstances would this affect us?

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

NewsArchive
04-15-2009, 01:34 AM
Hi Arnór,

>> Perfect. Then it's caused by the size of the return string. Changed in
>> SB7 now (to 10K) and SB6 (to 1K).
>
> In what kind of circumstances would this affect us?

It's possible that a "Call DLL Function..." return value (string or cstring
type) passed from a DLL back to the installer causes a silent buffer
overrun. The same can happen if you pass a string/cstring (> 511 bytes)
from the installer to the DLL.

Friedrich

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

NewsArchive
04-15-2009, 01:35 AM
By the way, this is not a Vista thing. It can happen on all OS.

Friedrich

NewsArchive
04-15-2009, 01:36 AM
Hi Friedrich,

> It's possible that a "Call DLL Function..." return value (string or cstring
> type) passed from a DLL back to the installer causes a silent buffer
> overrun. The same can happen if you pass a string/cstring (> 511 bytes)
> from the installer to the DLL.

Thanks:) I don't call dlls from any of my installs that I can recall so I
think I'm ok:)

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php