Vista - reflection, COM, and Vista

Hi all,
I've been struggling with an issue that I hope you can comment on or
provide suggestions to. Our .NET 2.0 (VS2005) based product is
crashing (when the user selects a particular feature on the UI) on
Vista. It works fine on XP. In a nutshell:

- user makes a selection on the UI
- System.Reflection.MethodInfo.Invoke() calls into one of our .NET
library dlls
- Inside the library dll, System.Activator.CreateInstance() is called
to create a particular .NET class object
- Inside the constructor of the .NET class object, a Thread is created
and started
- Inside the ThreadStart method, a COM object (created in VS2003 using
C++/ATL) is created
- Inside the FinalConstruct() of the COM object, Create() is called to
create a Window (in ATLWIN.h, Win32's CreateWindowEx() is eventually
called)
- CreateWindowEx() crashes with an access violation (0xc0000005)

Again, happens only on Vista....and happens every time. XP works
fine.
I'd really appreciate your help here. Thanks!

<idoublepress@xxxxxx> wrote in message
news:b1f75eef-0400-4737-bcf5-6d39fea4c4c3@xxxxxxYou are aware of the Vista UAC Manifest that a program running on Vista must
use to escalate its privileges so that it has the proper permissions when
needed during program execution.

Also, you cannot expect that a solution that was built on a XP machine and
deployed to a Vista machine is going to work Vista.

One builds and deploys a solution on a XP machine to be deployed to the XP
platform. One does the same for a solution to be deployed to Vista -- XP to
XP and Vista to Vista build and deployment. Although they are both NT
classed O/S(s), Vista is different under the hood in lots of areas from a
programming standpoint.

As long as there is only Net used it should problemless go, before we get
misunderstandings

Cor

"Cor Ligthert[MVP]" <notmyfirstname@xxxxxx> wrote in message
news8769085-4B84-44E2-AC35-106429FEDE08@xxxxxxThat is not correct. A DLL that is dedicated to the XP platform can be
picked up in the build that is not Vista compliant and stop things from
working or the other way around if it was built on Vista and deployed XP.

It's another form of DLL he*l, which I have faced and is a major cause of
problems on the Vista platform when solutions are built for the XP platform
and deployed to Vista. You see these issues in the Vista NG with users. And
it will happen even if .Net DLL(s) are not registered in the registry.

I recall a couple years back when a .Net solution was deployed to a Citrix
Terminal Server farm, the 3rd party vendor indicating there should be no
problems with existing solutions running on the server farm, because .Net
DLL(s) are not registered. Well, that was not the case and whole lot of
things start blowing out when that solution it the farm. The solution had to
be removed.

One must face the bullet coming at one in the foxhole.

"Cor Ligthert[MVP]" <notmyfirstname@xxxxxx> wrote in message
news8769085-4B84-44E2-AC35-106429FEDE08@xxxxxx

<snipped>

<correction>

when that solution hit the farm

On Jun 18, 5:09*pm, "Mr. Arnold" <MR. Arn...@xxxxxx> wrote:Thanks for replying. This issue is happening under the local
administrator account so I don't think that it's related to UAC
elevation. Any other ideas here? I was thinking that it has to be
something peculiar about Vista when doing the gyrations that I listed
above:

- user makes a selection on the UI
- System.Reflection.MethodInfo.Invoke() calls into one of our .NET
library dlls
- Inside the library dll, System.Activator.CreateInstance() is called
to create a particular .NET class object
- Inside the constructor of the .NET class object, a Thread is
created
and started
- Inside the ThreadStart method, a COM object (created in VS2003
using
C++/ATL) is created
- Inside the FinalConstruct() of the COM object, Create() is called
to
create a Window (in ATLWIN.h, Win32's CreateWindowEx() is eventually
called)
- CreateWindowEx() crashes with an access violation (0xc0000005)

<idoublepress@xxxxxx> wrote in message
news:5ae0c290-9d40-4d05-80be-42d5b07e8264@xxxxxx
On Jun 18, 5:09 pm, "Mr. Arnold" <MR. Arn...@xxxxxx> wrote:Thanks for replying. This issue is happening under the local
administrator account so I don't think that it's related to UAC
elevation. Any other ideas here? I was thinking that it has to be
something peculiar about Vista when doing the gyrations that I listed
above:

- user makes a selection on the UI
- System.Reflection.MethodInfo.Invoke() calls into one of our .NET
library dlls
- Inside the library dll, System.Activator.CreateInstance() is called
to create a particular .NET class object
- Inside the constructor of the .NET class object, a Thread is
created
and started
- Inside the ThreadStart method, a COM object (created in VS2003
using
C++/ATL) is created
- Inside the FinalConstruct() of the COM object, Create() is called
to
create a Window (in ATLWIN.h, Win32's CreateWindowEx() is eventually
called)
- CreateWindowEx() crashes with an access violation (0xc0000005)

--------------------------------------------------------------------------------
<copied>
The UAC team took a drastically different approach to designing the access
token creation process in Windows Vista. When an administrator user logs on
to a Windows Vista computer, two access tokens are created: a filtered
standard user access token and a full administrator access token. By
default, all users, including administrators, log on to Windows Vista as
standard users.

<copied>

So, the program can be running under an admin account up until the point
that it does something and the program's privileges must be escalated, and
it can't do so because the UAC manifest as not been addressed to say that
the running application can escalate its privileges.

Also, have you taken this application and with the .Net IDE compiled it and
ran it in debug mode on a Vista machine? I would say without doing that, you
are just shooting blanks. You cannot expect that the application that runs
on a XP is going to run on Vista without code modification. You're lucky if
that application can run on Vista without modification, but you are facing
that bullet.

The other thing you can do is turn UAC off and see if the program will run.





..

On Jun 19, 1:47*pm, "Mr. Arnold" <MR. Arn...@xxxxxx> wrote:Thanks for the additional suggestions. I turned off UAC but no
luck...still crashes at the same CreateWindowEx() call. I agree being
able to debug this would be good. But this crash is in a Win32
CreateWindowEx() call...not easy to figure out what's going on.
Complicating this is that the CreateWindowEx() crash is in the
FinalConstruct() of a COM component written in VS2003. Sucks to be
me... If anyone else has any other suggestions I'd appreciate it.

<idoublepress@xxxxxx> wrote in message
news:ae7b887e-84a1-460a-8c33-db255f00848d@xxxxxx
On Jun 19, 1:47 pm, "Mr. Arnold" <MR. Arn...@xxxxxx> wrote:Thanks for the additional suggestions. I turned off UAC but no
luck...still crashes at the same CreateWindowEx() call. I agree being
able to debug this would be good. But this crash is in a Win32
CreateWindowEx() call...not easy to figure out what's going on.
Complicating this is that the CreateWindowEx() crash is in the
FinalConstruct() of a COM component written in VS2003. Sucks to be
me... If anyone else has any other suggestions I'd appreciate it.


There are two different admin accounts on Vista. One is call the super Admin
account that has all inclusive rights, like the one on XP, and the user
Admin account which I think is still locked down to standard user, even with
UAC disable.

http://www.computerperformance.co.uk...r_activate.htm

Try that, as I still think you have a permissions issue that you may be
ignoring by the non-usage of the UAC manifest in usage by the program in
question.

Regardless as to what is happening here, you must be learning something
about Vista I would think.

On Jun 20, 6:34*pm, "Mr. Arnold" <MR. Arn...@xxxxxx> wrote:I confimed that the current Administrator account that I'm using is
active using the Net User method and the Local Securit Method as
described in the link you provided above. I'm sure that I'm
definately running the super-user administrator account. XP Prof
works fine for me...just that some customers are moving to Vista so I
need to figure this CreateWindowEx crash out...makes no sense to me.
I wonder if there's just something different about how Vista does
things during window creation or if its less tolerant than XP on
certain preconditions existing during a CreateWindowsEx call? Or if
there's something in the fact that the COM object is using ATL from
VS2003 and its being used in a VS2005 based application running on
Vista? Or maybe is some weird threading/apartment issue that only
shows up in Vista? I'll keep investigating...hopefully someone out
there has seen something similar before....Thanks.