473,326 Members | 2,173 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

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 2830
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: _R | last post by:
I've tried generating a couple console apps under VS2005 b2. The debugger brings up a window, but no output from WriteLine. ReadLine also seems to hang. Programs run fine outside of VS2005. ...
2
by: clintonG | last post by:
I forgot the distinction -- if any -- and wonder why I would want the SDK installed if I had VS2005 Pro installed? I've just learned the SDK requires SSE to be installed for QuickStart samples....
6
by: Brad | last post by:
I have a win2003 server workstation with multiple webs, each web has it's own ip address. In VS2005, if I select to open an existing web site, select Local IIS, the dialog correctly displays a...
1
by: guy | last post by:
i have a simple (1 form) Winforms VB.net 2003 app and am migrating it to vb2005 testing both on the same box... if i run the 2003 version it works correctly, but the 2005 version fails when...
3
by: Paul Lennon | last post by:
Hi, I hope I have selected the right group for this question, I am looking for assistance with using VS2005 to create a simple website on my ISP. Using VS2005 I have created a Website project...
0
by: GT | last post by:
This question has been posted before, but without any response so therefore I'm trying once more. I'm trying to embed .resource files into a Windows application in VS2005, and then compile and...
2
by: fineman | last post by:
Hi all, I want to get a 64bit(8 bytes) Encrypt result use DES class in the VS2005. Though I encrypt data is 64bit(8 bytes), but DES return encrypt result that always is 128bit(16 bytes), I don't...
3
by: Thomas | last post by:
Hi, I have written a simple console program in VS2005 and it should run on computers that dosn't have .NET (not 1.1 and not 2.0). I think it depends on the headerfiles? I have exculded the...
4
by: pinkmonkey4ever | last post by:
I have a VC6 ANSI C (console) project that I have recompiled sucessfully under VS2005. However, when I attempt to debug the code (step through) - my breakpoints are disabled (msg : "beakpoints...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.