As opposed to an expected one?

Losing what's left of my hair over this one...

My accounting app written in VB6 SP6 is crashing.  But only on one machine 
at a client's site.  What's really strange is that my app was running until 
some arbitrary update (I update several times a week on average) and he's 
not been able to run any updates past a specific one.  Yet those same 
updates run just fine on all the other computers on the network on-site. 
The only one that fails with "Unexpected Error" is the one running terminal 
services (or whatever it's called now) under Windows 2003.  They have a 
remote site accessing the package, been running fine for months, now 
suddenly won't work on anything past a certain release.  Of course, a custom 
change they needed is on one of the later releases.  Where its failing is 
the main module load, which has not been modified for at least a year.

Nevertheless, I have placed debugging code (high-tech msgboxes!) all over 
the place in the form_Initialize event, then in the form_load event.  He 
gets all the messages in form_initialize, then the dreaded "Unexpected 
Error" message.  Thinking it must be some event in between initialize and 
load, I added the same debugging messages to all events that had code - same 
result.  Then I added debugging messages to all events, period - same 
result.  Then I ran a trace on my own to see what other events might be 
occurring between initialize and load, and at least on my machine, no other 
events happen between those two.

I am sure it almost has to be terminal services, since nobody else is 
getting this error anywhere, and there are hundreds of other users.

Please, I"m down to about four or five hairs on my head!  Please help me 
save the follicles!

Bill "Frisbee" Hileman
Newly-designated Owner of Hamelin Software
http://www.hamelinsoftware.com

What kind of a control are you using in the left side of the app?
Looks like something from vbAccelerator, judging from the screenshot on 
your website.
This would be my first guess for an source of error.

Boris Pauljev wrote:
> What kind of a control are you using in the left side of the app?
> Looks like something from vbAccelerator, judging from the screenshot
> on your website.
> This would be my first guess for an source of error.

Nice catch.  It isn't vaAccelerator, but it is Infragistics Outlook Bar and 
Explorer controls.

Problem is, I have not altered -anything- on that main form for at least a 
year, and the program -was- running just fine up until a couple of week ago. 
I did suspect it was a form_resize event, since I do indeed alter the size 
of the outlook bar, explorer, and two command buttons based on previous 
settings stored in the registry, but the resize event is apparently not 
fired until the form is shown, and it never even enters the form_load event 
on that machine.

"Frisbee�" <discgolfdad@gEEmail.com> wrote in message 
news:uMOI5oN2KHA.1016@TK2MSFTNGP02.phx.gbl...
> Boris Pauljev wrote:
>> What kind of a control are you using in the left side of the app?
>> Looks like something from vbAccelerator, judging from the screenshot
>> on your website.
>> This would be my first guess for an source of error.
>
> Nice catch.  It isn't vaAccelerator, but it is Infragistics Outlook Bar 
> and Explorer controls.
>
> Problem is, I have not altered -anything- on that main form for at least a 
> year, and the program -was- running just fine up until a couple of week 
> ago. I did suspect it was a form_resize event, since I do indeed alter the 
> size of the outlook bar, explorer, and two command buttons based on 
> previous settings stored in the registry, but the resize event is 
> apparently not fired until the form is shown, and it never even enters the 
> form_load event on that machine.

Controls are loaded between Form_Initialize and Form_Load. 

"Frisbee�" <discgolfdad@gEEmail.com> schrieb im Newsbeitrag 
news:uMOI5oN2KHA.1016@TK2MSFTNGP02.phx.gbl...
>
> Problem is, I have not altered -anything- on that main form for at least a 
> year, and the program -was- running just fine up until a couple of week ago. I 
> did suspect it was a form_resize event, since I do indeed alter the size of 
> the outlook bar, explorer, and two command buttons based on previous settings 
> stored in the registry, but the resize event is apparently not fired until the 
> form is shown, and it never even enters the form_load event on that machine.
>

This is just a wild guess triggered by MS Photo Editor (known to store
erroneous values for its windows position in the registry and next run its
window is out of sight):
Has your program already retrieved those values from the registry?
Are they in the expected range? Maybe they cause the crash.
Does your program check those values or just pass them to the controls?

Helmut.

Helmut Meukel wrote:
> "Frisbee�" <discgolfdad@gEEmail.com> schrieb im Newsbeitrag
> news:uMOI5oN2KHA.1016@TK2MSFTNGP02.phx.gbl...
>>
>> Problem is, I have not altered -anything- on that main form for at
>> least a year, and the program -was- running just fine up until a
>> couple of week ago. I did suspect it was a form_resize event, since
>> I do indeed alter the size of the outlook bar, explorer, and two
>> command buttons based on previous settings stored in the registry,
>> but the resize event is apparently not fired until the form is
>> shown, and it never even enters the form_load event on that machine.
>
> This is just a wild guess triggered by MS Photo Editor (known to store
> erroneous values for its windows position in the registry and next
> run its window is out of sight):
> Has your program already retrieved those values from the registry?
> Are they in the expected range? Maybe they cause the crash.
> Does your program check those values or just pass them to the
> controls?
> Helmut.

That was my very first suspicion.  There was a time when I would store the 
windows position settings without checking windowstate, and subsequently if 
a user closed the application with one or more windows minimized, it would 
later attempt to restore the window as minimized but fail because it was 
also trying to set position.  Likewise, a user can go "hog-wild" when trying 
to resize the outlook bar and explorer panes, but I've since set minimum and 
maximum values for those as well.  Getting the settings is the first thing 
that the app does in the form_load event, but my debugging code would be 
displaying a message that it at least got that far in the debug mode, and 
it's not. 

Nobody wrote:
> "Frisbee�" <discgolfdad@gEEmail.com> wrote in message
> news:uMOI5oN2KHA.1016@TK2MSFTNGP02.phx.gbl...
>> Boris Pauljev wrote:
>>> What kind of a control are you using in the left side of the app?
>>> Looks like something from vbAccelerator, judging from the screenshot
>>> on your website.
>>> This would be my first guess for an source of error.
>>
>> Nice catch.  It isn't vaAccelerator, but it is Infragistics Outlook
>> Bar and Explorer controls.
>>
>> Problem is, I have not altered -anything- on that main form for at
>> least a year, and the program -was- running just fine up until a
>> couple of week ago. I did suspect it was a form_resize event, since
>> I do indeed alter the size of the outlook bar, explorer, and two
>> command buttons based on previous settings stored in the registry,
>> but the resize event is apparently not fired until the form is
>> shown, and it never even enters the form_load event on that machine.
>
> Controls are loaded between Form_Initialize and Form_Load.

I did not know that, but it makes sense.

In addition to the Infragistics ActiveX controls, it also loads an 8.5 
instance of Crystal Reports, several Pervasive (Btrieve) ActiveX controls, 
and probably a dialog control.

Is there something about loading controls via Terminal Services that could 
cause a problem that you're aware of?  Keeping in mind that I have not 
updated any of the controls in a very long time, either, meaning neither 
form nor controls should have changed in any way between the versions that 
worked and the subsequent versions that do not.

For what it's worth, I even tried switching between native code and p-code, 
and several of the various native code compile options - no combination 
seemed to make a difference (but I was surprised that the p-code exe was 33% 
smaller than the native code).

I'm thinking I probably need to look at his installation logs (I use Inno 
Setup) and see if perhaps he's getting some kind of error during the 
install.  The guy is pretty sharp - a power user (at least compared to most 
of my customers) so I can't believe he's ignoring an error message during 
install, but you never know.

Thanks for the pointers.

"Frisbee�" <discgolfdad@gEEmail.com> wrote in message 
news:uBA8e7O2KHA.5588@TK2MSFTNGP06.phx.gbl...
> Is there something about loading controls via Terminal Services that could 
> cause a problem that you're aware of?

No. The only issues with Terminal Services that I am aware of are multi-user 
issues, such as opening files exclusively in a local computer, which would 
not work, or trying to use the same hardware resource, such as COM1, etc.

You can test your app with Terminal Services if you have XP or after. Just 
create another user account, and log in. You can switch between sessions 
using the welcome screen or using Start-->Log off-->Switch User. Note that 
some network adapters replace GINA and this disables the welcome screen. 
Search MSKB for "GINA welcome screen" in how to restore it. The welcome 
screen is also disabled if the computer was configured to log in to a 
domain. This is also explained in MSKB.

Good luck!

"Nobody" <nobody@nobody.com> wrote in message 
news:OuglZ4S2KHA.5680@TK2MSFTNGP02.phx.gbl...
> "Frisbee�" <discgolfdad@gEEmail.com> wrote in message 
> news:uBA8e7O2KHA.5588@TK2MSFTNGP06.phx.gbl...
>> Is there something about loading controls via Terminal Services that 
>> could cause a problem that you're aware of?
>
> No. The only issues with Terminal Services that I am aware of are 
> multi-user issues, such as opening files exclusively in a local computer, 
> which would not work, or trying to use the same hardware resource, such as 
> COM1, etc.
>
> You can test your app with Terminal Services if you have XP or after. Just 
> create another user account, and log in. You can switch between sessions 
> using the welcome screen or using Start-->Log off-->Switch User. Note that 
> some network adapters replace GINA and this disables the welcome screen. 
> Search MSKB for "GINA welcome screen" in how to restore it. The welcome 
> screen is also disabled if the computer was configured to log in to a 
> domain. This is also explained in MSKB.

Also, if you are saving options to a per computer location, then one user 
could overwrite another user settings. If you are using a per user location 
or HKEY_CURRENT_USER, then it's not a problem. Each logged on user has its 
own copy of HKEY_CURRENT_USER.

"Frisbee�" <discgolfdad@gEEmail.com> wrote in message 
news:uBA8e7O2KHA.5588@TK2MSFTNGP06.phx.gbl...
> Nobody wrote:
>> "Frisbee�" <discgolfdad@gEEmail.com> wrote in message
>> news:uMOI5oN2KHA.1016@TK2MSFTNGP02.phx.gbl...
>>> Boris Pauljev wrote:
>>>> What kind of a control are you using in the left side of the app?
>>>> Looks like something from vbAccelerator, judging from the screenshot
>>>> on your website.
>>>> This would be my first guess for an source of error.
>>>
>>> Nice catch.  It isn't vaAccelerator, but it is Infragistics Outlook
>>> Bar and Explorer controls.
>>>
>>> Problem is, I have not altered -anything- on that main form for at
>>> least a year, and the program -was- running just fine up until a
>>> couple of week ago. I did suspect it was a form_resize event, since
>>> I do indeed alter the size of the outlook bar, explorer, and two
>>> command buttons based on previous settings stored in the registry,
>>> but the resize event is apparently not fired until the form is
>>> shown, and it never even enters the form_load event on that machine.
>>
>> Controls are loaded between Form_Initialize and Form_Load.
>
> I did not know that, but it makes sense.
>
> In addition to the Infragistics ActiveX controls, it also loads an 8.5 
> instance of Crystal Reports, several Pervasive (Btrieve) ActiveX controls, 
> and probably a dialog control.
>
> Is there something about loading controls via Terminal Services that could 
> cause a problem that you're aware of?  Keeping in mind that I have not 
> updated any of the controls in a very long time, either, meaning neither 
> form nor controls should have changed in any way between the versions that 
> worked and the subsequent versions that do not.
>
> For what it's worth, I even tried switching between native code and 
> p-code, and several of the various native code compile options - no 
> combination seemed to make a difference (but I was surprised that the 
> p-code exe was 33% smaller than the native code).
>
> I'm thinking I probably need to look at his installation logs (I use Inno 
> Setup) and see if perhaps he's getting some kind of error during the 
> install.  The guy is pretty sharp - a power user (at least compared to 
> most of my customers) so I can't believe he's ignoring an error message 
> during install, but you never know.
>
> Thanks for the pointers.
>
>

I would be tempted to check for an updated file on one of the controls you 
are using.

We had similar problems ultimately tracked down to an OCX that was newer on 
the client machine than my development machine.  I think in this particular 
case, said OCX had been updated as part of installing a printer.  Of course 
these OCX files are supposed to be backwards compatible, but they aren't 
always....

Tinker

Nobody wrote:
> "Nobody" <nobody@nobody.com> wrote in message
> news:OuglZ4S2KHA.5680@TK2MSFTNGP02.phx.gbl...
>> "Frisbee�" <discgolfdad@gEEmail.com> wrote in message
>> news:uBA8e7O2KHA.5588@TK2MSFTNGP06.phx.gbl...
>>> Is there something about loading controls via Terminal Services that
>>> could cause a problem that you're aware of?
>>
>> No. The only issues with Terminal Services that I am aware of are
>> multi-user issues, such as opening files exclusively in a local
>> computer, which would not work, or trying to use the same hardware
>> resource, such as COM1, etc.
>>
>> You can test your app with Terminal Services if you have XP or
>> after. Just create another user account, and log in. You can switch
>> between sessions using the welcome screen or using Start-->Log
>> off-->Switch User. Note that some network adapters replace GINA and
>> this disables the welcome screen. Search MSKB for "GINA welcome
>> screen" in how to restore it. The welcome screen is also disabled if
>> the computer was configured to log in to a domain. This is also
>> explained in MSKB.
>
> Also, if you are saving options to a per computer location, then one
> user could overwrite another user settings. If you are using a per
> user location or HKEY_CURRENT_USER, then it's not a problem. Each
> logged on user has its own copy of HKEY_CURRENT_USER.

I am using the GetSetting and SaveSetting functions, which I am pretty sure 
use the hkey_current_user settings.

The main form does open files (login ID's, security, etc.) but not in 
exclusive mode.  I also do not access hardware directly.  I do check the 
printers collection.

You've given me a lot more questions to ask the client, at least.  Thanks. 

Tinker wrote:
> "Frisbee�" <discgolfdad@gEEmail.com> wrote in message
> news:uBA8e7O2KHA.5588@TK2MSFTNGP06.phx.gbl...
>> Nobody wrote:
>>> "Frisbee�" <discgolfdad@gEEmail.com> wrote in message
>>> news:uMOI5oN2KHA.1016@TK2MSFTNGP02.phx.gbl...
>>>> Boris Pauljev wrote:
>>>>> What kind of a control are you using in the left side of the app?
>>>>> Looks like something from vbAccelerator, judging from the
>>>>> screenshot on your website.
>>>>> This would be my first guess for an source of error.
>>>>
>>>> Nice catch.  It isn't vaAccelerator, but it is Infragistics Outlook
>>>> Bar and Explorer controls.
>>>>
>>>> Problem is, I have not altered -anything- on that main form for at
>>>> least a year, and the program -was- running just fine up until a
>>>> couple of week ago. I did suspect it was a form_resize event, since
>>>> I do indeed alter the size of the outlook bar, explorer, and two
>>>> command buttons based on previous settings stored in the registry,
>>>> but the resize event is apparently not fired until the form is
>>>> shown, and it never even enters the form_load event on that
>>>> machine.
>>>
>>> Controls are loaded between Form_Initialize and Form_Load.
>>
>> I did not know that, but it makes sense.
>>
>> In addition to the Infragistics ActiveX controls, it also loads an
>> 8.5 instance of Crystal Reports, several Pervasive (Btrieve) ActiveX
>> controls, and probably a dialog control.
>>
>> Is there something about loading controls via Terminal Services that
>> could cause a problem that you're aware of?  Keeping in mind that I
>> have not updated any of the controls in a very long time, either,
>> meaning neither form nor controls should have changed in any way
>> between the versions that worked and the subsequent versions that do
>> not. For what it's worth, I even tried switching between native code and
>> p-code, and several of the various native code compile options - no
>> combination seemed to make a difference (but I was surprised that the
>> p-code exe was 33% smaller than the native code).
>>
>> I'm thinking I probably need to look at his installation logs (I use
>> Inno Setup) and see if perhaps he's getting some kind of error
>> during the install.  The guy is pretty sharp - a power user (at
>> least compared to most of my customers) so I can't believe he's
>> ignoring an error message during install, but you never know.
>>
>> Thanks for the pointers.
>>
>>
>
> I would be tempted to check for an updated file on one of the
> controls you are using.
>
> We had similar problems ultimately tracked down to an OCX that was
> newer on the client machine than my development machine.  I think in
> this particular case, said OCX had been updated as part of installing
> a printer.  Of course these OCX files are supposed to be backwards
> compatible, but they aren't always....

I can understand the logic behind that, and I may have him check versions 
anyway, but I doubt that could be the problem, since re-installing an older 
version of my own app seems to solve the problem AND the fact that after 
installing a newer version of my app, he CAN run it locally, but the failure 
happens when running from the remote terminal.  How could an ActiveX control 
run correctly on the local machine, but not on a remote via terminal 
services?  If I understand TS correctly, it acts as nothing more than 
something like CrossLoop or even RDP in that it runs 100% on the local 
server, and just transmits screens and input back and forth literally like 
the old time "dumb" terminals did, so if it runs on the local machine, why 
would it not run remotely, and why would one version of the executable work 
on both machines, and another only on the local?  I've not updated any ocx 
or dll files in a long time, certainly not since the version that stopped 
working.

Thanks for your input. 

Frisbee� wrote:
> As opposed to an expected one?
>
> Losing what's left of my hair over this one...
>
> My accounting app written in VB6 SP6 is crashing.  But only on one
> machine at a client's site.  What's really strange is that my app was
> running until some arbitrary update (I update several times a week on
> average) and he's not been able to run any updates past a specific
> one.  Yet those same updates run just fine on all the other computers
> on the network on-site. The only one that fails with "Unexpected
> Error" is the one running terminal services (or whatever it's called
> now) under Windows 2003.  They have a remote site accessing the
> package, been running fine for months, now suddenly won't work on
> anything past a certain release.  Of course, a custom change they
> needed is on one of the later releases.  Where its failing is the
> main module load, which has not been modified for at least a year.
> Nevertheless, I have placed debugging code (high-tech msgboxes!) all
> over the place in the form_Initialize event, then in the form_load
> event.  He gets all the messages in form_initialize, then the dreaded
> "Unexpected Error" message.  Thinking it must be some event in
> between initialize and load, I added the same debugging messages to
> all events that had code - same result.  Then I added debugging
> messages to all events, period - same result.  Then I ran a trace on
> my own to see what other events might be occurring between initialize
> and load, and at least on my machine, no other events happen between
> those two.
> I am sure it almost has to be terminal services, since nobody else is
> getting this error anywhere, and there are hundreds of other users.
>
> Please, I"m down to about four or five hairs on my head!  Please help
> me save the follicles!
>
> Bill "Frisbee" Hileman
> Newly-designated Owner of Hamelin Software
> http://www.hamelinsoftware.com

I won't know until sometime tomorrow when the user tests my solution, but I 
think I've finally located the source of my problem.

It was the installer!  I use Inno Setup (and highly recommend it) and I 
hadn't updated the program in ages, but figured it was probably about time I 
did, what with Windows 7 and all.  The main reason I decided to get an 
update, though, was because after reading their newsgroups, I discovered 
that Jordan Russel (the author) had recently added a new feature to allow 
the setup builder to do code-signing from within (which saves me having to 
run a batch file afterwards, plus also code-signs the included uninstall 
module).

On a hunch, I searched his help file for "Terminal Services" and discovered 
that he'd added a new setting called "TerminalServicesAware" and defaulted 
it to "Yes."  Apparently programs to be installed on a terminal services 
computer must use a special method, or at least be installed through 
"add/remove programs" instead of being run just from the setup.exe, and this 
new feature apparently "returns the true Windows folder" or something to 
that effect.  This would explain why ActiveX controls might suddenly not be 
found, I would think.

So, I've added the flag and set it to "No" so at least in theory, it should 
now behave like it did before I updated the setup builder.  Notified the 
client, and in fact, suggested that he first try his latest download 
installed "normally" instead of as he had been for terminal services.  If 
that didn't work, then he needs to download and install my latest on the web 
site and install his "normal" way.

In case anyone's interested, I'll post the results when I hear back from 
him.

"Frisbee�" <discgolfdad@gEEmail.com> wrote in message 
news:eT3m%23Jd2KHA.6048@TK2MSFTNGP06.phx.gbl...
> I won't know until sometime tomorrow when the user tests my solution, but 
> I think I've finally located the source of my problem.
>
> It was the installer!  I use Inno Setup (and highly recommend it) and I 
> hadn't updated the program in ages, but figured it was probably about time 
> I did, what with Windows 7 and all.  The main reason I decided to get an 
> update, though, was because after reading their newsgroups, I discovered 
> that Jordan Russel (the author) had recently added a new feature to allow 
> the setup builder to do code-signing from within (which saves me having to 
> run a batch file afterwards, plus also code-signs the included uninstall 
> module).
>
> On a hunch, I searched his help file for "Terminal Services" and 
> discovered that he'd added a new setting called "TerminalServicesAware" 
> and defaulted it to "Yes."  Apparently programs to be installed on a 
> terminal services computer must use a special method, or at least be 
> installed through "add/remove programs" instead of being run just from the 
> setup.exe, and this new feature apparently "returns the true Windows 
> folder" or something to that effect.  This would explain why ActiveX 
> controls might suddenly not be found, I would think.
>
> So, I've added the flag and set it to "No" so at least in theory, it 
> should now behave like it did before I updated the setup builder. 
> Notified the client, and in fact, suggested that he first try his latest 
> download installed "normally" instead of as he had been for terminal 
> services.  If that didn't work, then he needs to download and install my 
> latest on the web site and install his "normal" way.
>
> In case anyone's interested, I'll post the results when I hear back from 
> him.

Sometimes under Terminal Services(I think if run from a terminal session 
only, not from the physical console), GetWindowsDirectory() returns a 
different folder rather than the real Windows folder. This is done for 
compatibility with applications that use the Windows folder to store their 
INI file. When you put a Terminal Server in install mode(by using Add/Remove 
Programs), Windows disables this redirection temporarily. See this page for 
more details:

http://www.jrsoftware.org/ishelp/topic_setup_terminalservicesaware.htm

You really need to leave this flag at the default "Yes", which tells Windows 
to always return the real Windows folder. If you use "No", then Windows 
could return either the real one or the fake one, which is not a good idea 
for an installer that tries to update files. Obviously, the installer in 
this case would not find the existing version of the file, and installs what 
you have, which could be an older version.

If you are doing some extra installation activities from your VB app and you 
are calling GetWindowsDirectory(), then call SHGetSpecialFolderLocation() 
with CSIDL_WINDOWS flag to get the real Windows folder.

I doubt you've resolved it.
I would rather think that it's a crash in the ocx.
Or maybe you are using a vbaccelerator image list or the outlook bar 
developer did?

I just experienced unexpected crashes (reproducable) on one user's machine.
It was due to a VBAcc imagelist. On www.10tec.com I found a newer, 
maintained version of it which resolved the problem.

My applications are used being used on around 1000 machines, and it 
occured only on one computer (XP), I have no idea what went wrong, but 
if ocx'es were not already on place 1 on my crash list, they would have 
been after this incidence.

Missing controls never give you unexpected runtime errors, they give 
catachable VB6 errors.

Nobody wrote:
> "Frisbee�" <discgolfdad@gEEmail.com> wrote in message
> news:eT3m%23Jd2KHA.6048@TK2MSFTNGP06.phx.gbl...
>> I won't know until sometime tomorrow when the user tests my
>> solution, but I think I've finally located the source of my problem.
>>
>> It was the installer!  I use Inno Setup (and highly recommend it)
>> and I hadn't updated the program in ages, but figured it was
>> probably about time I did, what with Windows 7 and all.  The main
>> reason I decided to get an update, though, was because after reading
>> their newsgroups, I discovered that Jordan Russel (the author) had
>> recently added a new feature to allow the setup builder to do
>> code-signing from within (which saves me having to run a batch file
>> afterwards, plus also code-signs the included uninstall module).
>>
>> On a hunch, I searched his help file for "Terminal Services" and
>> discovered that he'd added a new setting called
>> "TerminalServicesAware" and defaulted it to "Yes."  Apparently
>> programs to be installed on a terminal services computer must use a
>> special method, or at least be installed through "add/remove
>> programs" instead of being run just from the setup.exe, and this new
>> feature apparently "returns the true Windows folder" or something to
>> that effect.  This would explain why ActiveX controls might suddenly
>> not be found, I would think. So, I've added the flag and set it to "No" 
>> so at least in theory, it
>> should now behave like it did before I updated the setup builder.
>> Notified the client, and in fact, suggested that he first try his
>> latest download installed "normally" instead of as he had been for
>> terminal services.  If that didn't work, then he needs to download
>> and install my latest on the web site and install his "normal" way.
>>
>> In case anyone's interested, I'll post the results when I hear back
>> from him.
>
> Sometimes under Terminal Services(I think if run from a terminal
> session only, not from the physical console), GetWindowsDirectory()
> returns a different folder rather than the real Windows folder. This
> is done for compatibility with applications that use the Windows
> folder to store their INI file. When you put a Terminal Server in
> install mode(by using Add/Remove Programs), Windows disables this
> redirection temporarily. See this page for more details:
>
> http://www.jrsoftware.org/ishelp/topic_setup_terminalservicesaware.htm
>
> You really need to leave this flag at the default "Yes", which tells
> Windows to always return the real Windows folder. If you use "No",
> then Windows could return either the real one or the fake one, which
> is not a good idea for an installer that tries to update files.
> Obviously, the installer in this case would not find the existing
> version of the file, and installs what you have, which could be an
> older version.
> If you are doing some extra installation activities from your VB app
> and you are calling GetWindowsDirectory(), then call
> SHGetSpecialFolderLocation() with CSIDL_WINDOWS flag to get the real
> Windows folder.

I understand your point, and I may not have solved it, however I did read 
that help screen page before, and the part that stuck with me, to at least 
try it, was the suggestion that you keep it at the default of "yes" unless 
you've had problems since installing with the newer version - which 
describes me to a "T"  If it doesn't work, I do have other things I can look 
at, like trying to run the app from the server under the remote user's ID, 
which I don't think he's tried yet.  I don't know how "permissions" could be 
the problem here, but it's a possibility, at least.

Thanks again for your detailed feedback.  For a "nobody" you sure are 
somebody. 

Boris Pauljev wrote:
> I doubt you've resolved it.
> I would rather think that it's a crash in the ocx.
> Or maybe you are using a vbaccelerator image list or the outlook bar
> developer did?
>
> I just experienced unexpected crashes (reproducable) on one user's
> machine. It was due to a VBAcc imagelist. On www.10tec.com I found a
> newer, maintained version of it which resolved the problem.
>
> My applications are used being used on around 1000 machines, and it
> occured only on one computer (XP), I have no idea what went wrong, but
> if ocx'es were not already on place 1 on my crash list, they would
> have been after this incidence.
>
> Missing controls never give you unexpected runtime errors, they give
> catachable VB6 errors.

You may be right, Boris, after reading Nobody's explanation too.  And it may 
well be some kind of ocx problem, but why then would re-installing a 
previous version work?  Even in the instance you mentioned earlier where the 
target machine may have a newer version which is not backward compatible? 
Wouldn't it continue to fail when the older version is restored?  This 
danged thing is going to be the death of me. 

Frisbee� wrote:
> Nobody wrote:
>> "Frisbee�" <discgolfdad@gEEmail.com> wrote in message
>> news:eT3m%23Jd2KHA.6048@TK2MSFTNGP06.phx.gbl...
>>> I won't know until sometime tomorrow when the user tests my
>>> solution, but I think I've finally located the source of my problem.
>>>
>>> It was the installer!  I use Inno Setup (and highly recommend it)
>>> and I hadn't updated the program in ages, but figured it was
>>> probably about time I did, what with Windows 7 and all.  The main
>>> reason I decided to get an update, though, was because after reading
>>> their newsgroups, I discovered that Jordan Russel (the author) had
>>> recently added a new feature to allow the setup builder to do
>>> code-signing from within (which saves me having to run a batch file
>>> afterwards, plus also code-signs the included uninstall module).
>>>
>>> On a hunch, I searched his help file for "Terminal Services" and
>>> discovered that he'd added a new setting called
>>> "TerminalServicesAware" and defaulted it to "Yes."  Apparently
>>> programs to be installed on a terminal services computer must use a
>>> special method, or at least be installed through "add/remove
>>> programs" instead of being run just from the setup.exe, and this new
>>> feature apparently "returns the true Windows folder" or something to
>>> that effect.  This would explain why ActiveX controls might suddenly
>>> not be found, I would think. So, I've added the flag and set it to
>>> "No" so at least in theory, it
>>> should now behave like it did before I updated the setup builder.
>>> Notified the client, and in fact, suggested that he first try his
>>> latest download installed "normally" instead of as he had been for
>>> terminal services.  If that didn't work, then he needs to download
>>> and install my latest on the web site and install his "normal" way.
>>>
>>> In case anyone's interested, I'll post the results when I hear back
>>> from him.
>>
>> Sometimes under Terminal Services(I think if run from a terminal
>> session only, not from the physical console), GetWindowsDirectory()
>> returns a different folder rather than the real Windows folder. This
>> is done for compatibility with applications that use the Windows
>> folder to store their INI file. When you put a Terminal Server in
>> install mode(by using Add/Remove Programs), Windows disables this
>> redirection temporarily. See this page for more details:
>>
>> http://www.jrsoftware.org/ishelp/topic_setup_terminalservicesaware.htm
>>
>> You really need to leave this flag at the default "Yes", which tells
>> Windows to always return the real Windows folder. If you use "No",
>> then Windows could return either the real one or the fake one, which
>> is not a good idea for an installer that tries to update files.
>> Obviously, the installer in this case would not find the existing
>> version of the file, and installs what you have, which could be an
>> older version.
>> If you are doing some extra installation activities from your VB app
>> and you are calling GetWindowsDirectory(), then call
>> SHGetSpecialFolderLocation() with CSIDL_WINDOWS flag to get the real
>> Windows folder.
>
> I understand your point, and I may not have solved it, however I did
> read that help screen page before, and the part that stuck with me,
> to at least try it, was the suggestion that you keep it at the
> default of "yes" unless you've had problems since installing with the
> newer version - which describes me to a "T"  If it doesn't work, I do
> have other things I can look at, like trying to run the app from the
> server under the remote user's ID, which I don't think he's tried
> yet.  I don't know how "permissions" could be the problem here, but
> it's a possibility, at least.
> Thanks again for your detailed feedback.  For a "nobody" you sure are
> somebody.

What's just occurred to me is that I am probably right in that something in 
Inno Setup caused my problem, it's probably just NOT the 
TerminalServicesAware flag.  Now, If I could just remember what my old Inno 
Setup version was BEFORE I updated it, then I could go back and read all the 
notes of the upgrades, and perhaps some other new "feature" is what broke my 
application on Terminal Services?  Ugh.  I'm still hoping that this somehow 
fixes it. 

I don't understand why you have not managed to track the real position 
of where the error occured.
When you don't do anything in the code, nothing will happen, so there 
has to be a call that throws the error.
I still don't believe in the terminal services being the cause of the error.

I have managed to crash VB6 in many ways (manifest, imagelists, vbAcc, 
CopyMemory, UAC, ocx), but before you or anybody else can help you, you 
should first really track down where the error occurs.
If you are happy with the msgbox, go on, but I have already had 
situations where even the messageboxes crashed/ were not shown, so I did 
something like this:

sub main
	writelog "1"
	do this
	writelog "2"
	do that
	writelog "3"
	...etc
end sub

private sub Writelog(byval uString as string)

	dim sPath$
	'sPath = GetSpecialFolder(CSIDL_DESKTOP) & "\" & App.ExeName & "_LOG.log"
         sPath = "C:\" & App.Exename & "_LOG.txt"

	Dim iFileNr%
         iFileNr = FreeFile()

         Open sPath For Append As #iFileNr
         Print #iFileNr, uString
         Close #iFileNr

end sub

Boris Pauljev wrote:
> I don't understand why you have not managed to track the real position
> of where the error occured.
> When you don't do anything in the code, nothing will happen, so there
> has to be a call that throws the error.
> I still don't believe in the terminal services being the cause of the
> error.
> I have managed to crash VB6 in many ways (manifest, imagelists, vbAcc,
> CopyMemory, UAC, ocx), but before you or anybody else can help you,
> you should first really track down where the error occurs.
> If you are happy with the msgbox, go on, but I have already had
> situations where even the messageboxes crashed/ were not shown, so I
> did something like this:
>
> sub main
> writelog "1"
> do this
> writelog "2"
> do that
> writelog "3"
> ...etc
> end sub
>
> private sub Writelog(byval uString as string)
>
> dim sPath$
> 'sPath = GetSpecialFolder(CSIDL_DESKTOP) & "\" & App.ExeName &
>         "_LOG.log" sPath = "C:\" & App.Exename & "_LOG.txt"
>
> Dim iFileNr%
>         iFileNr = FreeFile()
>
>         Open sPath For Append As #iFileNr
>         Print #iFileNr, uString
>         Close #iFileNr
>
> end sub

Part of the problem, Boris, is that I cannot duplicate the problem on my 
computer, only on the end-user's computer.  It would seem that the 
form_initialize event is fully running, since it is displaying all the 
msgbox commands, but never entering the form_load event.  I'm told that the 
form's controls are loaded in between those two events.  I could write 
something like you've shown, and I have done that sort of debugging in the 
past, but I suspect it will produce the same as the message boxes - write up 
until form_initialize is done, then nothing else - error.

I may have test the theory of it being the install utility by using a 
different third-party install which would be no easy task.  It's a fairly 
complex accounting application.  Moving it to another installer would be 
quite the chore, as it was moving it from Wise Installer to Inno several 
years ago.  However, that might be the only way I can determine for sure if 
it's the installer or not.  Right now, Boris, I have no freaking idea what 
the cause of this is - terminal services, Inno Setup, both, neither, I have 
no idea and it's driving me nuts.  This particular client is one of my 
favorites and I've known him for decades.  He's got to be losing faith in 
me, I wouldn't blame him. 

Frisbee� wrote:
....

> Part of the problem, Boris, is that I cannot duplicate the problem on my 
> computer, only on the end-user's computer.  ...

Well, there's a hint there...you need to look into what's on the machine 
besides that's different.

The other thing that strikes me is that you say you can go back to an 
earlier version an remove the problem on the same machine.  If that is 
so, I'd start from the last place that it does work and then 
incrementally make updates and find out what it is that breaks it.

--

"Frisbee�" <discgolfdad@gEEmail.com> wrote in message 
news:e8rblDy2KHA.5820@TK2MSFTNGP06.phx.gbl...
> I cannot duplicate the problem on my computer, only on the end-user's 
> computer.

You might be able to duplicate it by doing the following:

- Download and install the free Virtual PC.
- Download Windows 2008 Server trial version in ISO format, 32 Bit 
edition(The 64 bit version is not supported on Virtual PC), or if you 
prefer, the VHD version which saves you installation time.
- Create a new virtual machine in Virtual PC, and assign 512 MB of RAM to 
the new OS, leave other options at the default. In Networking, choose the 
adapter that you normally use, don't use "Shared Networking". If you are 
using the VHD version, use it instead of creating a new hard drive image.
- If installing from ISO image, start the new VM and press Delete to go to 
the BIOS. In Virtual PC menu, go to CD-->Capture ISO Image, and browse to 
the ISO file. There is no need to burn it on a CD or DVD first.
- Install the new OS, this would take about 25 minutes.
- Once the installation is finished, shut it down, then go to "My Virtual 
Machines" folder under My Documents and backup the whole folder. This is 
your clean installation copy in case you want to go back to it, so you don't 
have to reinstall the OS again.
- In Virtual PC menu, go to Action-->Install or Update Virtual Machines 
Additions. This allows you to do Copy and Paste and drag and drop files 
between the host and guest OS'es.
- Terminal Services Role by default is not installed. You need to install 
it. I think this is done by going to "Programs and Features" in Control 
Panel. It can also be done from other places.
- Now, in both machines, use "ipconfig" to see if the IP addresses are 
similar, then use "Ping <Other IP>" to see if you get replies. If not, 
change the options as needed.
- To connect to Terminal Services from your XP or Vista machine, use "Remote 
Desktop Connection" under Start-->All 
Programs-->Accessories--Communications.
- Enter the Win2008 computer name(or its IP), you will be asked for user 
name and password. Leave the domain name blank, or if you have problems, set 
it to the same as the Win2008 computer name. Once you click Connect, you 
should see a full desktop inside a window. Now run your installer and test 
it.

You could enable "Undo Disks", so if you screwed up, you can just click the 
"X" on Virtual PC, and tell it to discard the changes. This would revert it 
to the last saved state.

Some links:

Virtual PC 2007 SP1:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=28c97d22-6eb8-4a09-a7f7-f6c7a1f000b5

Windows Server 2008 R2 Evaluation (180 days):
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ba571339-5436-4cf5-9c37-6ed7dab6f781

Other ways to download:
http://www.microsoft.com/windowsserver2008/en/us/try-it.aspx

Can you state the controls that you are using on the form in question?
Which imagelist are you using?

Or did you perhaps change the icon of your form?
Some icons cause crashes on some computers.

Boris Pauljev wrote:
> Or did you perhaps change the icon of your form?
> Some icons cause crashes on some computers.

Holy cow.  Yes, in fact I did.  Since I took over the business and started 
my own corporation, I created an icon from my new company logo, then 
proceeded to replace the old icon in all forms.

That is certainly worth testing.  If this turns out to be it, I owe you 
(only figuratively, though... I'm broke)

Thank you for the tip.

Boris Pauljev wrote:
> Can you state the controls that you are using on the form in question?
> Which imagelist are you using?

Here's a snippet from my Inno Install Script:

(note CS ocx's are Crescent Software)

; begin App Specific ActiveX
Source: C:\WinProd\System32\Comct332.OCX; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Comdlg32.OCX; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Cscmd32.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Cslist32.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Cstext32.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Imp32x20.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Mschrt20.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Mscomctl.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Mscomct2.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Msdatgrd.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Msflxgrd.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\Program Files\Infragistics\Data Explorer\PVOutlookBar.ocx; 
DestDir: {sys}; Flags: sharedfile regserver
Source: C:\Program Files\Infragistics\Data Explorer\PVXplore8.ocx; DestDir: 
{sys}; Flags: sharedfile regserver
Source: C:\Program Files\ReSizOCX\Resize32.ocx; DestDir: {sys}; Flags: 
sharedfile regserver
Source: C:\WinProd\System32\Sysinfo.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\Program Files\Tabpro20\Bin\Tab32x20.ocx; DestDir: {sys}; Flags: 
sharedfile regserver
Source: C:\WinProd\System32\Tidate8.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Timask8.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Tinumb8.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Tinumbl8.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Titext8.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Todg7.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Todg8.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Todl8.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Vsflex8.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Xadb7.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Xadb8.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Xarraydb.ocx; DestDir: {sys}; Flags: sharedfile 
regserver
; end App Specific ActiveX

; begin App Specific DLL
Source: C:\WinProd\System32\Ctl3d32.dll; DestDir: {sys}; Flags: sharedfile
Source: C:\WinProd\System32\Mfcans32.dll; DestDir: {sys}; Flags: sharedfile
Source: C:\WinProd\System32\Msvcirt.dll; DestDir: {sys}; Flags: sharedfile
Source: C:\WinProd\System32\Oledlg.dll; DestDir: {sys}; Flags: sharedfile
Source: C:\WinProd\System32\Tdbgpp8.dll; DestDir: {sys}; Flags: sharedfile
Source: C:\WinProd\System32\Tibase8.dll; DestDir: {sys}; Flags: sharedfile
Source: C:\WinProd\System32\Tishare8.dll; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Todgub7.dll; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Todgub8.dll; DestDir: {sys}; Flags: sharedfile 
regserver
Source: C:\WinProd\System32\Vbalflbr.dll; DestDir: {sys}; Flags: sharedfile
Source: C:\WinProd\System32\c4dll.dll; DestDir: {sys}; Flags: sharedfile
; end App Specific DLL 

Cool :-)

Frisbee� wrote:
> Boris Pauljev wrote:
>> Or did you perhaps change the icon of your form?
>> Some icons cause crashes on some computers.
> 
> Holy cow.  Yes, in fact I did.  Since I took over the business and started 
> my own corporation, I created an icon from my new company logo, then 
> proceeded to replace the old icon in all forms.
> 
> That is certainly worth testing.  If this turns out to be it, I owe you 
> (only figuratively, though... I'm broke)

Don't you have this tested already?  Didn't you say you had an earlier 
version which did _NOT_ crash?  Does it have the new corporate icon?

I'll not say this can't happen; I'm having a hard time figuring out how 
it would have anything to do with it from "just an icon".

Maybe Boris can shed some light on the "how/why?" of that...

--

I think the customer has 16 bit set up in graphics cards, and there is 
something in the icon that makes VB6 crash in this combination.
But I don't know how that can happen.

dpb wrote:
> Frisbee� wrote:
>> Boris Pauljev wrote:
>>> Or did you perhaps change the icon of your form?
>>> Some icons cause crashes on some computers.
>>
>> Holy cow.  Yes, in fact I did.  Since I took over the business and
>> started my own corporation, I created an icon from my new company
>> logo, then proceeded to replace the old icon in all forms.
>>
>> That is certainly worth testing.  If this turns out to be it, I owe
>> you (only figuratively, though... I'm broke)
>
> Don't you have this tested already?  Didn't you say you had an earlier
> version which did _NOT_ crash?  Does it have the new corporate icon?

The earlier version did not have the new icon.  I have confirmed that much 
with the client.  I also have determined that for some reason, the current 
icon was likely a 145k .ico file - I have no idea why it was so big, but I 
also cannot confirm this, since VB does NOT show the current file or 
location for the icon property of the forms, only lets you select a new one. 
I have re-created via a favicon creator on the web a .ico file which is 4-5k 
and contains both 16x16 and 32x32 versions.  Since my app has approximately 
100 forms, all of which were using the icon, the compiled size of the 
updated icon was significantly smaller.  I actually sent a version of the 
program with the old, original icon in the main and logon forms to the 
client.  I'm hoping he'll let me know shortly if it worked.

> I'll not say this can't happen; I'm having a hard time figuring out
> how it would have anything to do with it from "just an icon".
>
> Maybe Boris can shed some light on the "how/why?" of that...

You got me, except that it would make sense that the icon would be one of 
the things loaded, as a resource, along with the controls after 
form_initialize and before form_load.  If the .ico file was somehow invalid 
(which does look like the case) it's possible that terminal services is 
particularly finicky about its format, whereas windows itself is not?

Regardless, I sure do hope this is it. 

Frisbee� wrote:
> dpb wrote:
>> Frisbee� wrote:
>>> Boris Pauljev wrote:
>>>> Or did you perhaps change the icon of your form?
>>>> Some icons cause crashes on some computers.
>>> Holy cow.  Yes, in fact I did.  Since I took over the business and
>>> started my own corporation, I created an icon from my new company
>>> logo, then proceeded to replace the old icon in all forms.
>>>
>>> That is certainly worth testing.  If this turns out to be it, I owe
>>> you (only figuratively, though... I'm broke)
>> Don't you have this tested already?  Didn't you say you had an earlier
>> version which did _NOT_ crash?  Does it have the new corporate icon?
> 
> The earlier version did not have the new icon.  ...

Ah, so...

>> I'll not say this can't happen; I'm having a hard time figuring out
>> how it would have anything to do with it from "just an icon".
>>
>> Maybe Boris can shed some light on the "how/why?" of that...
> 
> You got me, except that it would make sense that the icon would be one of 
> the things loaded, as a resource, along with the controls after 
> form_initialize and before form_load.  If the .ico file was somehow invalid 
> (which does look like the case) it's possible that terminal services is 
> particularly finicky about its format, whereas windows itself is not?
....

I'd think it far more likely it's the machines video driver/hardware 
rather than terminal services...but, if it fixes the problem that will 
be good, agreed (and a new one for me).

--