Visual Studio 6.0 installs but messes with XPe

[Lee]

I have installed Visual Studio 6.0 Enterprise with no errors but I
have a problem with Computer Management, I created some users and a
user group but when I try to add users to a group I receive an error
message as follows:


Microsoft Visual C++ Runtime Library

Program: C:\WINDOWS\system32\mmc.exe

R6025
- pure virtual function call


The lovely Microsoft site says my code is using a function call it
shouldnt and I should rewrite my code, haha rewrite Windows, nice one!
Please help someone!

 

[KM]

Lee,

What are the connections between VS and Computer Management?
Are you sure the error happened because of the VS install? If you are, please verify the version of msvcrt*.dll libraries you have
got under \windows\system32. They should be the latest ones from XPE Repository.

You might have not satisfied all the VS dependencies. You may want to use tools like DependencyWalker, Regmon, FileMon to catch
what's missing.
Some issues regarding installing VC++ at run time have been discussed in this NG:
http://groups.google.com/groups?hl=...a=group=microsoft.public.windowsxp.embedded.*

Btw, what are the reasons that you want VS to run on your runtime? If it is for debugging purposes, you may want to switch to VS
Remote Debuggin instead or use remote debuggers like WinDbg.

KM

 

[Lee]

Ah I am making different setups with different software on them but
all use the same base XPe image.

I have performed these tasks successfully before on machines without
MS Visual Studio 6.0

I have tried running through the installs and I can carry out the user
and group tasks up until I install MSVS 6.0 then it stops working and
gives me this error. I am leaving work at the moment but I will look
up the things you mentioned first thing tomorrow and post them up
here.

These are development machines and need Visual Studio 6.0 for
developming a variety of applications and drivers so need the whole
package.

Lee

 

[Slobodan Brcin \(eMVP\)]

Hi Lee,

You should not use machines with XPe as development machines for your programs and drivers, but you should use them rather as test
machines trough remote debugging for test purposes only.

Regards,
Slobodan

 

[Lee]

I don't mean to be rude but wether you think I should or shouldn't be
using these machines for development, that is what we will be using
and should be capable of doing so, it's my job to get it working not
my decision.

Can anyone help me figure out why I am getting this error message as
MSVS 6.0 is the only thing left for me to do and my job will be done
lol

Thanks for any help
Lee

 

[KM]

Lee,

I think you misunderstood Slobodan's reply. He suggested you to use remote debugging option instead of wasting your time trying to
get VS running at the run time.

Anyway, it is not clear what kind of help you are looking for.
The error you see could be a result of pretty much anything.
Did you try using the tools I mentioned above? What were the results?
Did you get all the VS dependencies in your runtime?

 

[Desi Richards]

Slobodon,

That seems very restrictive and on the surface seems unnecessary. Do
you know of any specific areas that break when you try to run VS on a
target?

Obviously you will have to test on a clean target, but if your target
device is a PC then why should you go through the trouble of windbg???

Desi

 

[Lee]

Also in reply to KM these are my file versions:

msvcrt20.dll - version 2.12.000
msvcrt40.dll - version 4.2000.0.6201
msvcrt.dll - version 7.0.2600.1106
msvcrtd.dll - version 6.0.8168.0

Hope this helps
Lee

 

[Slobodan Brcin \(eMVP\)]

Hi Desi,

I said remote debugging in general not just windbg. And no I have not tried to install VS on XPe but there are answers in this NG
from people who did use:
http://groups.google.com/groups?hl=...F-8&group=microsoft.public.windowsxp.embedded

WinDbg is good for drivers, but you can trace your code from remote VS trough TCP-IP. Just need to start msvcmon on windows XPe
(which is easily accomplished). Also this way you won't need to add too much needles things to XPe as you would be required if you
installed VS.

Anyhow check licensing restrictions of XPe, I have no idea if running VS on XPe is allowed or not :-(

Regards,
Slobodan

 

[Slobodan Brcin \(eMVP\)]

Hi Lee,

I hope that you are aware that file protection is not working under XPe and when you install VS it could install older dll files
instead of files provided by XPe.
Use file compare on XPe folder that you backuped before and after installation of VS. And find if any of original file was changed.

Regards,
Slobodan

 

[Lee]

To quote Slobodan:
"You should not use machines with XPe as development machines for your
programs and drivers but you should use them rather as test machines
trough remote debugging for test purposes only"

I did not misunderstand at all, we need to use these machines as
development machines and not for remote debugging...

I will try running the DependencyWalker application you mention.

Lee

 

[Jochen Kalmbach]

Hi Lee,

I did not misunderstand at all, we need to use these machines as
development machines and not for remote debugging...

Did you read the EULA !?
As far as I know this is not allowed... (ok, I do not have the eula by
hand..., so maybe there is only a restriction for Office)

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Lee]

Seeing as it is mmc.exe that is causing the problem I opened it in
Dependency Walker and received 2 warnings:

Warning: At least one delay-load dependency module was not found
WArning: At least one module has an unresolved import due to a missing
export function in a delay-load dependency module

In the list of modules i have:

W32TOPL.DLL - Error opening file. The system cannot find the file
specified (2)

MPR.DLL has one entry in the list on the left that is red
(WNetRestoreConnectionA)

I then ran a profile and I shall provide the errors:

LoadLibraryA("C:\WINDOWS\System32\MFC42LOC.DLL")returned NULL by
thread 1.Error: The specified module could not be found (126)

loads of GetProcAddres errors, an example:

GetProcAddress(0x77D40000[c:\windows\system32\USER32.DLL],"GetAccCursorInfo")
called from "c:\windows\system32\OLEACC.DLL" at address 0x74C838D3 and
returned NULL by thread 1. Error: The specified procedure could not be
found (127)

I don't understand all of this output but hopefully someone might have
more of an idea than me about what is causing the problems

Thanks if you do
Lee

 

[Slobodan Brcin \(eMVP\)]

Hi Lee,

EULA is probably your only obstacle here that you (someone) should check first.
I misunderstood you then. I thought that you could use some other approach instead of installing VS on XPe :-(
If not then good luck, and read my response at the root of this thread.

Regards,
Slobodan

 

[KM]

Lee,

Look like SP1 ones.
Is this before or after you installed VS?

 

[KM]

Lee,

Verify if "Primitive: W32topl" and "Accessibility Core" components were included in your Configuration.

Also, it seems that you have installed a localized version of MFC. If you install any locale DLL, you must ensure the locale for
which the DLL is intended matches the locale of the installed Windows system. When you install the DLL, you must rename it to
Mfc42loc.dll.

Please read this article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/redistribvc6.asp

--
Regards,
KM, BSquare Corp.

Seeing as it is mmc.exe that is causing the problem I opened it in
Dependency Walker and received 2 warnings:

Warning: At least one delay-load dependency module was not found
WArning: At least one module has an unresolved import due to a missing
export function in a delay-load dependency module

In the list of modules i have:

W32TOPL.DLL - Error opening file. The system cannot find the file
specified (2)

MPR.DLL has one entry in the list on the left that is red
(WNetRestoreConnectionA)

I then ran a profile and I shall provide the errors:

LoadLibraryA("C:\WINDOWS\System32\MFC42LOC.DLL")returned NULL by
thread 1.Error: The specified module could not be found (126)

loads of GetProcAddres errors, an example:

GetProcAddress(0x77D40000[c:\windows\system32\USER32.DLL],"GetAccCursorInfo")
called from "c:\windows\system32\OLEACC.DLL" at address 0x74C838D3 and
returned NULL by thread 1. Error: The specified procedure could not be
found (127)

I don't understand all of this output but hopefully someone might have
more of an idea than me about what is causing the problems

Thanks if you do
Lee

Lee,

I think you misunderstood Slobodan's reply. He suggested you to use remote debugging option instead of wasting your time trying to
get VS running at the run time.

Anyway, it is not clear what kind of help you are looking for.
The error you see could be a result of pretty much anything.
Did you try using the tools I mentioned above? What were the results?
Did you get all the VS dependencies in your runtime?

--
Regards,
KM, BSquare Corp.

as
test libraries
you
have to
catch switch
to VS

 

[Lee]

KM,

Those were after installing VS.

I have "Accessibility Core" but do not have "Primitive: W32topl" would
this cause my problem?

It just seems strange that it should work without VS, I shall do a
fresh install of XPe and take a copy of the System32 folder then
install VS and see what changes.

Lee

 

[Lee]

OK I have just been comparing file versions and was wondering if you
always want a newer version of a dll because after installing VS 6.0
some of my dlls in the system32 folder are older versions.

I've only just started looking but starting from the top i found
activeds.dll was version 5.1.2600.0 and is now version 4.1.110.1

Is it safe to re-register the newer dlls over the old ones?

Thank you
Lee

 

[Slobodan Brcin \(eMVP\)]

Hi Lee,

Have you seen my post from yesterday:

I hope that you are aware that file protection is not working under XPe and when you install VS it could install older dll files
instead of files provided by XPe.
Use file compare on XPe folder that you backuped before and after installation of VS. And find if any of original file was changed.

Newer dll's (without some bug) should be always compatible with previous versions. Vice versa is not true.

So reregister new dll's again.

Regards,
Slobodan

 

[KM]

Slobodan,

Hi Lee,

Have you seen my post from yesterday: changed.

Newer dll's (without some bug) should be always compatible with previous versions. Vice versa is not true.

So reregister new dll's again.

He would unlikely need to re-register Dlls as he's got the newer versions of them in pre-FBA image and therefore they were registers
(with all the newer possible interfaces) during FBA. It is very, very unlikely that CLSIDs got changed in newer Dlls.
Just the dlls replacement should work.