View Full Version : Internal error V1

12-19-2003, 11:39 AM
A user of our software reported getting the following error while attempting to install the software. We used IS7 Professional to create the install. Then we used vBuild 1.0 to create the final installation package.

The error is:
"Internal error V1, please contact support.
Installation will now terminate."

From the screen shot sent to us by the user, this message appears during the Scouting phase of the install. Also, it appears he is running on a Chinese version of Windows XP, if that makes any difference.

This is a very generic error message. Any ideas? Thanks in advance!

12-21-2003, 05:37 AM
This error usually happens on double-byte versions of Windows XP or Windows 2000. These Windows versions support multiple users and the default temporary folder is located under a path that includes a user name. If the user name includes double-byte characters, e.g. Kanji, vBuild will fail with the error you report. Lack of support of double-byte characters in file and folder names is a known limitation of vBuild. The error will not occur on Windows 98 and XP, as the temporary path there does not include user name.

If the cause of the error is indeed double-bytes in username, then the following workaround to change the default temporary folder location will solve the problem:

1. Right click the My Computer icon on desktop and choose Properties
2. Click Advanced tab, then Environment Variables button. An Environment Variables dialog opens, where the top part is called "User variables for <UserName>"
3. One of the variables is TEMP. Select it and click the Edit button. The default is usually %USERPROFILE%\Local Settings\Temp. Write this down so it can be restored later.
4. Change this setting to an absolute path on any drive where there is plenty of disk space, e.g. to c:\mytemp.
5. Click OK to close the dialogs.
6. Run vBuild-enabled installation
7. Repeat steps 1-4 to restore TEMP under "User variables for <UserName>" back to %USERPROFILE%\Local Settings\Temp or whatever value it had previously.

I hope this helps.


12-29-2003, 03:58 PM

When exactly can we expect a maintenance release, hotfix, or "in script" workaround to address this problem?

This is killing my support department with calls from customers encountering this problem. It reflects poorly on our product, and there is nothing we can do about it.

I understand the changing of the %TEMP% variable workaround, but a better workaround would be if I could detect the scenario in my install script, and make the change there for vBuild to aviod this error. Currently, our support department is working around this by providing such customers a pointer to a non-vBuild version of our product installation.

12-29-2003, 04:08 PM
The work-around described is also not a solution we can use. The work-around we must use also is to provide a non-vBuild install to affected users. Since we have just encountered this problem with one user, we have yet to determine how many users are affected and if there are quite a number, then we will basically have to post to our users two versions of the installs, which makes extra work for us each time we release new versions of our programs and is potentially confusing to our users.

We, too, look forward to an eventual vBuild solution to this problem.