• Create Account

## Compiling release version in microsoft visual c++ 2010

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

15 replies to this topic

### #1Ussyless  Members

Posted 25 January 2011 - 05:44 AM

Hi, so im trying to compile my project so that it can run on other computers, on the net is says all i have to do is change to release mode and set it to multi-threaded in compile options
when i do this i cant run the exe(without error) even on my own computer, i can run it when i use multi-threaded dll, but i cant run it on any other computers

My friend is getting an error saying " the program cant start because MSVCP100D.dll is missing from your computer"

### #2Monkan  Members

Posted 25 January 2011 - 07:08 AM

It should work,

Make sure its set to release mode then go to Project -> Properties -> Configuration Properties -> C++ -> Code Generation

and change the runtime library to Multi-threaded (/MT)

If you are in debug mode you should change it to Multi-threaded Debug (/MTd)

Works fine for me and that is the error associated with it.

Posted 25 January 2011 - 07:15 AM

It's correct that you set the project to release mode, since the debug runtimes are only installed with visual studio, which your consumer most likely won't have. You (and any user) must install the Visual C++ 2010 Redistributable. This installs the release runtime (which should contain that missing dll, for example).

### #4Ussyless  Members

Posted 25 January 2011 - 07:23 AM

error associated with multi threaded compile is
First-chance exception at 0x00401a02 in SpaceSpeedster.exe: 0xC0000005: Access violation reading location 0x39960273.
Unhandled exception at 0x00401a02 in SpaceSpeedster.exe: 0xC0000005: Access violation reading location 0x39960273.

just tested running a release compile with the same compile settings with a different project, and it worked for that one

### #5Monkan  Members

Posted 25 January 2011 - 07:27 AM

If you set the option in release mode as I have said then you don't need to install anything to make it run.....................

Just make sure you get the .exe out of the Release folder.

Posted 25 January 2011 - 07:40 AM

If you set the option in release mode as I have said then you don't need to install anything to make it run.....................

Your program will not run without the redistributable, not even if you wish for it. Chances are another program installed it, but that is not always the case.
However the error mentioned by the OP seems to indicate that he delivered a debug executable, instead of a release one (which is indicated by the d in the dll name: MSVCP100D.dll).

*edit*
It will only work if you link against the static runtime (in which case the runtime is included in your executable), however that has some drawbacks that might be confusing for newcomers.

### #7Ussyless  Members

Posted 25 January 2011 - 08:10 AM

i should say i tested all the multithreading options, i guess that error is just from when i tested the debug one, the other ones came up with the similar error "MSVCP100.dll"

### #8Aardvajk  Members

Posted 25 January 2011 - 08:58 AM

If the exe runs on your computer in debug but not in release (if I understand the above) then the chances are that there is a bug in your code that the debug build is supressing somehow. It's quite possible to have an error that does not produce a crash in debug but does in release.

I'll confirm again, just for the record, if you set Runtime Library to /MT then you do not need any of the redistributable on the target computer.

If you run your program in release mode from within the IDE, does it give you any more useful information about the cause of the crash? That's where I'd start, not buggering about with dependency issues - if it won't run on your PC, where we know we have the libraries as VS is installed, that isn't the problem.

Posted 25 January 2011 - 09:06 AM

I'll confirm again, just for the record, if you set Runtime Library to /MT then you do not need any of the redistributable on the target computer.

I'm sorry, I oversaw the /MT in the original comment, hence my reply: You only need the redistributable with the /MD switch.

### #10Burnt_Fyr  Members

Posted 25 January 2011 - 10:01 AM

error associated with multi threaded compile is
First-chance exception at 0x00401a02 in SpaceSpeedster.exe: 0xC0000005: Access violation reading location 0x39960273.
Unhandled exception at 0x00401a02 in SpaceSpeedster.exe: 0xC0000005: Access violation reading location 0x39960273.

just tested running a release compile with the same compile settings with a different project, and it worked for that one

99 times out of 100, if you see that error, it's an unitialized pointer. Step through the program(release build) line by line until you find the call using the pointer, and once you've found it, make sure it is initialized to null before use.

### #11AndyEsser  GDNet+

Posted 25 January 2011 - 05:34 PM

Unitialised variables tend to be the biggest issue when I'm unable to run a release version.

Also, it's not quite as simple as just selecting Release mode. If you have linked other libraries in the debug version (OpenGL, etc) then you will need to make sure you have the same Linker options in Release mode.

### #12yewbie  Members

Posted 25 January 2011 - 06:00 PM

MSVCP100.dll = Release mode dll file
MSVCP100D.dll = Debug mode dll file

If your friend is still getting the error with MSVCP100D.dll, you are not compiling with release mode, unless your statically linking to the dll in your code (as someone else mentioned above)
I think you may be dealing with 2 completely different issues here.

### #13Ussyless  Members

Posted 25 January 2011 - 09:29 PM

here is complete output when compiling

'SpaceSpeedster.exe': Loaded 'C:\Documents and Settings\kieran\My Documents\Visual Studio 2010\Projects\SpaceSpeedster\Release\SpaceSpeedster.exe', Binary was not built with debug information.
'SpaceSpeedster.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open the PDB file
'SpaceSpeedster.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or open the PDB file
'SpaceSpeedster.exe': Loaded 'C:\Program Files\Alwil Software\Avast5\snxhk.dll', Cannot find or open the PDB file
'SpaceSpeedster.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', Cannot find or open the PDB file
'SpaceSpeedster.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', Cannot find or open the PDB file
'SpaceSpeedster.exe': Loaded 'C:\WINDOWS\system32\secur32.dll', Cannot find or open the PDB file
'SpaceSpeedster.exe': Loaded 'C:\WINDOWS\system32\glut32.dll', Binary was not built with debug information.
First-chance exception at 0x00401a02 in SpaceSpeedster.exe: 0xC0000005: Access violation reading location 0x5913b07e.
Unhandled exception at 0x00401a02 in SpaceSpeedster.exe: 0xC0000005: Access violation reading location 0x5913b07e.



also yewbie, if you read that much you should have also seen

i should say i tested all the multithreading options, i guess that error is just from when i tested the debug one, the other ones came up with the similar error "MSVCP100.dll"

the linkers are the same for the debug & release also

dont think i've left anything undefined

what a paint this is >.>

### #14Ussyless  Members

Posted 27 January 2011 - 11:58 PM

OK, since i'm desperate, I've attached my source files, if anyone could tell me whats wrong, i'd be grateful (you may have to change some of the includes to your directories)
kinda new to c++ but i have experience in other languages, just gotta get used to this one, so i know some of my scripts might be a bit inefficient but thats not a problem for now.
thanks
will remove these files if/when this is solved

EDIT: sorry forgot to attach lol, they are on now

### #15Pomnico  Members

Posted 28 January 2011 - 02:21 AM

OK, since i'm desperate, I've attached my source files, if anyone could tell me whats wrong, i'd be grateful (you may have to change some of the includes to your directories)
kinda new to c++ but i have experience in other languages, just gotta get used to this one, so i know some of my scripts might be a bit inefficient but thats not a problem for now.
thanks
will remove these files if/when this is solved

What I have found after few moments:
- debug::pop - you declare line[20] but inside this method you try to set line[20] = line[19] (for i = 20)
- debug::draw -You are not calling delete on "a" varable. Why not passing to draw_string function "s.c_str()" directly?

Sorry, but I can't launch it atthe moment, so I would just give you short advice on how to look for such problems (in case of simple programs, like yours). Use printf to log current position in your program:
printf("LOG: %s(%d) : %s\n", __FILE__, __LINE__, __FUNCTION__);
Put it at the beginning of main and at end of main for start, as well as in the same way inside all callback functions registered to glut - display, keyboard, reshape, etc.
Run your program and look at end of log. If you see that program has entered inside some function, but has not returned from it when it has crashed, just tighten your logs inside that function, so you find what is causing this problem. If you need some additional info about variables values, etc. when the problem occurs, just add additional logs with it. If your problem is easy to reproduce, you will quickly find the reason. Just remember, that sometimes adding new logs will make the problem dissapear (compiler will organize assembly in a different way), but that's something you just have to take into consideration.

Regards
Pomnico

### #16Ussyless  Members

Posted 28 January 2011 - 02:29 AM

OK, since i'm desperate, I've attached my source files, if anyone could tell me whats wrong, i'd be grateful (you may have to change some of the includes to your directories)
kinda new to c++ but i have experience in other languages, just gotta get used to this one, so i know some of my scripts might be a bit inefficient but thats not a problem for now.
thanks
will remove these files if/when this is solved

What I have found after few moments:
- debug::pop - you declare line[20] but inside this method you try to set line[20] = line[19] (for i = 20)
- debug::draw -You are not calling delete on "a" varable. Why not passing to draw_string function "s.c_str()" directly?

Sorry, but I can't launch it atthe moment, so I would just give you short advice on how to look for such problems (in case of simple programs, like yours). Use printf to log current position in your program:
printf("LOG: %s(%d) : %s\n", __FILE__, __LINE__, __FUNCTION__);
Put it at the beginning of main and at end of main for start, as well as in the same way inside all callback functions registered to glut - display, keyboard, reshape, etc.
Run your program and look at end of log. If you see that program has entered inside some function, but has not returned from it when it has crashed, just tighten your logs inside that function, so you find what is causing this problem. If you need some additional info about variables values, etc. when the problem occurs, just add additional logs with it. If your problem is easy to reproduce, you will quickly find the reason. Just remember, that sometimes adding new logs will make the problem dissapear (compiler will organize assembly in a different way), but that's something you just have to take into consideration.

Regards
Pomnico

well funny thing about the debug::draw script was, i wrote it one day, and the next day i forgot what it did, so i thought it would be best not to mess with it lol
thanks for reply, ill see if i can find the issue

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.