Link to home
Start Free TrialLog in
Avatar of TBursch
TBursch

asked on

Running VC++ Profiler On Windows NT

Am trying, unsecussfully,  to run the VC++ Profiler.  

I have compiled my application in debug mode with the Enable Profiling check box at Project / Link / General dialog checked. But, when I click on the Profile menu item, the system complains that I haven't done that.

Noted that the Profiler is available only with Enterprise or Professional versions.   I am using the VC++
version 6 that came with our Universal subscription.
Is that the problem?   Am running NT.
Avatar of cwrea
cwrea
Flag of Canada image

Suggestion:  Run the profiler on a Release build.
Avatar of TBursch
TBursch

ASKER

Release or Debug does not seem to matter, I get the same complaint.  
Hmm What kind of application is it?  Console executable, Win32 app, DLL, etc.?

Are you running your Visual Studio 6 with Service Pack 5 installed?
I think you also have to activate "generate map file" and copy the map file to the exe directory.
PS: I always use command line version of the profiler and this works.
Use VC's batchfile FTIME.BAT:

FTIME exename exeparameter >destination.txt
Avatar of TBursch

ASKER

Pacman,
I had used Profile about a year ago and remember that there was some trick to getting it to run.   Your comment about the .map file triggered a memory and I was certain the map file was the key, but haven't been able to get it yet.   How about Debug Information? Does Profile need that?

I made the output paths myproject\release and myproject\debug so both the .exe and .map are going to the same place, but that didn't do it either.  

Am I supposed to be running Profile in Release or Debug mode?

cwrea,
My application is an .exe, very large, uses many DLLs and Libraries.  The executable is >4 mbyte.  A coworker is wondering about our Help file.   Every time we compile and run, VC complains that the help file is out of date and asks if we want to build it.   We usually just say NO.  He thinks that may be the reason Profile does not think our executable is up to date?

We are running NT v4.0, with service pack 5.

Thanks for your help guys, this is getting really frustrating for me.
tom
 
>> ... and I was certain the map file was the key, but
>> haven't been able to get it yet.

Don't you get the map file or don't you get it working with the map file ?

I always copy the mapfile to the exe directory. Then I start a command line ("DOS" box) and change to this directory. From there I call profiler via "FTIME.BAT", see above.

Did you try calling FTIME.BAT ?
Avatar of TBursch

ASKER

Pacman,
Yes, a .map file was created, and it has the same date and time as the .exe.   I have tried several things to put the .map and .exe in the same directory ... moved the .map to the same directory as the .exe, moved the .exe to the directory where the .map is, and changed the compiler settings so that the .exe is placed in the same directory as the .map.   None of these has made a difference.

I created a test project, just a SDI with no extra code, and was able to get the Profiler started for it.  I just tried compiling with the Enable Profiler box checked, and  the Build map File box not checked on the Settings / Link page.  Both the .exe and .map files were created.  Profiler started.   It started for both Release and Debug builds.

I've never used VC++ from a command line ... will try your suggestion today, though I don't know how to do that.
Do I start what used to be the DOS process and enter FTIME from that?

Still trying to get rid of the complaint about the .hlp file.  Even when I answer YES to querry about creating it, nothing is built, at least not a .hlp file.   Do you know how to turn creation of the .hlp file off?

tom
ASKER CERTIFIED SOLUTION
Avatar of Pacman
Pacman
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of TBursch

ASKER

Pacman,
Wonderful!   The command line trick is working very well,
Have gathered some good data.  A coworker is going wild,
working to get line timing data.

Thanks for your help.

tom