469,636 Members | 1,952 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,636 developers. It's quick & easy.

VS2005 Attempt to Run Simple Console App Fails

Two installations of VS 2005 Pro RTM. Same symptom with both.
Simple Win32 Console application compiles fine, but when I attempt to run
(with or without debugging), message appears: failed to find mdvcp80d.dll.
A search reveals the file is present (two instances, 1004 kb each).
Anybody else seen this? Any ideas how to rectify the situation?
Nov 17 '05 #1
10 2703
Ted
It appears that your manifest is not getting embedded properly, or your VC
DLLs are not installed in the correct place.

That file should be in

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8 b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c

If you open up your EXE as resources using the resource editor, you should
see a manifest file RT_MANIFEST as 1. It should have references to this
DLL, something like this:

<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT"
version="8.0.50608.0"

Ted.

"pvdg42" <pv****@newsgroups.nospam> wrote in message
news:Oe*************@TK2MSFTNGP10.phx.gbl...
Two installations of VS 2005 Pro RTM. Same symptom with both.
Simple Win32 Console application compiles fine, but when I attempt to run
(with or without debugging), message appears: failed to find mdvcp80d.dll.
A search reveals the file is present (two instances, 1004 kb each).
Anybody else seen this? Any ideas how to rectify the situation?

Nov 17 '05 #2
Ted
I should also mention that there also should be a file in:

C:\WINDOWS\WinSxS\Policies\x86_policy.8.0.Microsof t.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773

named:

8.0.50727.42.policy

and there should be a line in there like this:

<bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
newVersion="8.0.50727.42"/>

All information provided so far assumes you are using the RTM (i.e.
shipping) version of Visual Studio 2005.

Ted.

"Ted" <te*@t--x.org> wrote in message
news:uT**************@TK2MSFTNGP10.phx.gbl...
It appears that your manifest is not getting embedded properly, or your VC
DLLs are not installed in the correct place.

That file should be in

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8 b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c

If you open up your EXE as resources using the resource editor, you should
see a manifest file RT_MANIFEST as 1. It should have references to this
DLL, something like this:

<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT"
version="8.0.50608.0"

Ted.

"pvdg42" <pv****@newsgroups.nospam> wrote in message
news:Oe*************@TK2MSFTNGP10.phx.gbl...
Two installations of VS 2005 Pro RTM. Same symptom with both.
Simple Win32 Console application compiles fine, but when I attempt to run
(with or without debugging), message appears: failed to find
mdvcp80d.dll.
A search reveals the file is present (two instances, 1004 kb each).
Anybody else seen this? Any ideas how to rectify the situation?


Nov 17 '05 #3

"Ted" <te*@t--x.org> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...
I should also mention that there also should be a file in:

C:\WINDOWS\WinSxS\Policies\x86_policy.8.0.Microsof t.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773

named:

8.0.50727.42.policy

and there should be a line in there like this:

<bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
newVersion="8.0.50727.42"/>

All information provided so far assumes you are using the RTM (i.e.
shipping) version of Visual Studio 2005.

Ted.

"Ted" <te*@t--x.org> wrote in message
news:uT**************@TK2MSFTNGP10.phx.gbl...
It appears that your manifest is not getting embedded properly, or your
VC DLLs are not installed in the correct place.

That file should be in

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8 b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c

If you open up your EXE as resources using the resource editor, you
should see a manifest file RT_MANIFEST as 1. It should have references
to this DLL, something like this:

<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT"
version="8.0.50608.0"

Ted.


Yes, this is the Visual Studio 2005 Professional Edition RTM, as downloaded
from MSDN.

I installed it on a third PC in my office and have the same behavior from
all three instances.
I have verified the file MSVCP80D.dll exists in the location you specify.
However, I also find a second copy of the file at:

D:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86
\Microsoft.VC80.DebugCRT.

(Note: D: is the install drive, and the OS partition here.)
Could the second copy be causing the problem?
I have also verified the entry you cited in the 8.0.50727.42.policy file,
which is found in the location you specified.
However, when I looked in the debug folder for the .exe, there is no .exe to
be found, even though the output from build/rebuild shows 0 errors, 0
warnings, there is a link entry referring to the build log, where I find a
note indicating the .exe could not be found or created:

Compiling manifest to resources...
Linking...
LINK : E:\CIT1173\VS2005Test\Debug\VS2005Test.exe not found or not built by
the last incremental link; performing full link
Embedding manifest...
Results
Build log was saved at
"file://e:\CIT1173\VS2005Test\VS2005Test\Debug\BuildLog.ht m"
VS2005Test - 0 error(s), 0 warning(s)

But, no .exe!

So, it looks to me as if no executable is being created, but VS does not
consider that a problem?

I could swear this issue was not encountered in Beta 2, and creating empty
Win32 console projects, then having students create C++ programs to learn
language basics is essential to our classroom use of the product, just as
we've been doing with VS 6, VS.net 2002 and VS.NET 2003.

Sure hope there's a way to fix this.

Nov 17 '05 #4
Ted
I had the same problem as you did - I couldn't find the EXE.

Then I realized it makes two folders for some reason, e.g. in your case:

E:\CIT1173\VS2005Test\Debug\

and

E:\CIT1173\VS2005Test\VS2005Test\Debug\

The EXE file will be in the first folder, not the second. I'm not sure why
it has two folders like that. It did that for me with a default wizard
generated project. But in my case the EXE ran without any problems.

I think that the residual old version(s) of the CRT that you found on your
machine is causing the problems. I don't know how to clean it.

Ted.

"pvdg42" <pv****@newsgroups.nospam> wrote in message
news:OT**************@TK2MSFTNGP14.phx.gbl...

"Ted" <te*@t--x.org> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...
I should also mention that there also should be a file in:

C:\WINDOWS\WinSxS\Policies\x86_policy.8.0.Microsof t.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773

named:

8.0.50727.42.policy

and there should be a line in there like this:

<bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
newVersion="8.0.50727.42"/>

All information provided so far assumes you are using the RTM (i.e.
shipping) version of Visual Studio 2005.

Ted.

"Ted" <te*@t--x.org> wrote in message
news:uT**************@TK2MSFTNGP10.phx.gbl...
It appears that your manifest is not getting embedded properly, or your
VC DLLs are not installed in the correct place.

That file should be in

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8 b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c

If you open up your EXE as resources using the resource editor, you
should see a manifest file RT_MANIFEST as 1. It should have references
to this DLL, something like this:

<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT"
version="8.0.50608.0"

Ted.


Yes, this is the Visual Studio 2005 Professional Edition RTM, as
downloaded from MSDN.

I installed it on a third PC in my office and have the same behavior from
all three instances.
I have verified the file MSVCP80D.dll exists in the location you specify.
However, I also find a second copy of the file at:

D:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86
\Microsoft.VC80.DebugCRT.

(Note: D: is the install drive, and the OS partition here.)
Could the second copy be causing the problem?
I have also verified the entry you cited in the 8.0.50727.42.policy file,
which is found in the location you specified.
However, when I looked in the debug folder for the .exe, there is no .exe
to be found, even though the output from build/rebuild shows 0 errors, 0
warnings, there is a link entry referring to the build log, where I find a
note indicating the .exe could not be found or created:

Compiling manifest to resources...
Linking...
LINK : E:\CIT1173\VS2005Test\Debug\VS2005Test.exe not found or not built
by the last incremental link; performing full link
Embedding manifest...
Results
Build log was saved at
"file://e:\CIT1173\VS2005Test\VS2005Test\Debug\BuildLog.ht m"
VS2005Test - 0 error(s), 0 warning(s)

But, no .exe!

So, it looks to me as if no executable is being created, but VS does not
consider that a problem?

I could swear this issue was not encountered in Beta 2, and creating empty
Win32 console projects, then having students create C++ programs to learn
language basics is essential to our classroom use of the product, just as
we've been doing with VS 6, VS.net 2002 and VS.NET 2003.

Sure hope there's a way to fix this.


Nov 17 '05 #5
Hi,
Compiling manifest to resources...
Linking...
LINK : E:\CIT1173\VS2005Test\Debug\VS2005Test.exe not found or not built bythe last incremental link; performing full link
Embedding manifest...
Results
Build log was saved at
"file://e:\CIT1173\VS2005Test\VS2005Test\Debug\BuildLog.ht m"
VS2005Test - 0 error(s), 0 warning(s)


I agree with Ted's opinion, the output executable should be in the
directory:
E:\CIT1173\VS2005Test\Debug\

not the following one:
E:\CIT1173\VS2005Test\VS2005Test\Debug\

This is determined by the "Output File" setting in the console app project
properties' "Configuration Properties/Linker/General", it is specified as
"$(OutDir)\$(ProjectName).exe" as default, the $(OutDir) will be parsed as
E:\CIT1173\VS2005Test\Debug\
in your case.
Thanks!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ˇ§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default...sdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 17 '05 #6
On Mon, 14 Nov 2005 22:18:26 -0500, "Ted" <te*@t--x.org> wrote:
I had the same problem as you did - I couldn't find the EXE.

Then I realized it makes two folders for some reason, e.g. in your case:

E:\CIT1173\VS2005Test\Debug\

and

E:\CIT1173\VS2005Test\VS2005Test\Debug\

'
I've also wondered about that. I've also seen ..\obj\debug and
...\bin\debug, both with exe files. Does anyone know why VS creates
two folders?

Nov 17 '05 #7

"pvdg42" <pv****@newsgroups.nospam> wrote in message
news:OT**************@TK2MSFTNGP14.phx.gbl...

"Ted" <te*@t--x.org> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...
I should also mention that there also should be a file in:

C:\WINDOWS\WinSxS\Policies\x86_policy.8.0.Microsof t.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773

named:

8.0.50727.42.policy

and there should be a line in there like this:

<bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
newVersion="8.0.50727.42"/>

All information provided so far assumes you are using the RTM (i.e.
shipping) version of Visual Studio 2005.

Ted.

"Ted" <te*@t--x.org> wrote in message
news:uT**************@TK2MSFTNGP10.phx.gbl...
It appears that your manifest is not getting embedded properly, or your
VC DLLs are not installed in the correct place.

That file should be in

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8 b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c

If you open up your EXE as resources using the resource editor, you
should see a manifest file RT_MANIFEST as 1. It should have references
to this DLL, something like this:

<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT"
version="8.0.50608.0"

Ted.

OK, found the .exe and renamed the extra instances of MSVCP80D.DLL on the
two machines here at home. Now, all is well. I'll do the same at work later
today. I'm convinced, from the two installations here, that renaming or
deleting the extra files is the fix.
Thanks very much to you and to Gary for bailing me out!
Nov 17 '05 #8

"pvdg42" <pv****@newsgroups.nospam> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"pvdg42" <pv****@newsgroups.nospam> wrote in message
news:OT**************@TK2MSFTNGP14.phx.gbl...
OK, found the .exe and renamed the extra instances of MSVCP80D.DLL on the
two machines here at home. Now, all is well. I'll do the same at work
later today. I'm convinced, from the two installations here, that renaming
or deleting the extra files is the fix.
Thanks very much to you and to Gary for bailing me out!

Heh...
You know you're in trouble when you start answering your own posts.
The rename fix applied to the office PC did *not* fix the problem. Only
clear difference is that on that PC, VS 2005 was not installed on the OS
partition as it is here at home. I'm going to investigate further and follow
up on Gary's suggestion on the proper location for the .exe.
I'll report back what I discover...
Nov 17 '05 #9

"pvdg42" <pv****@newsgroups.nospam> wrote in message
news:Oe*************@TK2MSFTNGP10.phx.gbl...
Two installations of VS 2005 Pro RTM. Same symptom with both.
Simple Win32 Console application compiles fine, but when I attempt to run
(with or without debugging), message appears: failed to find mdvcp80d.dll.
A search reveals the file is present (two instances, 1004 kb each).
Anybody else seen this? Any ideas how to rectify the situation?

Just to put a stopper on this bottle:
The problem PC was not connected to a network, thus while SP2 (for Win XP)
was installed, it was missing numerous other updates. I hooked it up,
downloaded and installed all critical updates for Win XP, and all issues
with VS 2005 disappeared. Working fine now.
Lesson learned and something for me to remember if our MSDNAA-eligible
students report the same types of issues.
Nov 18 '05 #10
Bingo, I am delight to know you found the "bug" of this issue, I think we
also have such experience before or later...

Have a nice weekend!
Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ˇ§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default...sdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 19 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by _R | last post: by
2 posts views Thread by clintonG | last post: by
3 posts views Thread by Paul Lennon | last post: by
4 posts views Thread by pinkmonkey4ever | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.