Tried a lot different things, but what should be a simple thing never works for me. VSP file downloaded, but doesn't show my function names, only hex codes. It does give an error:
Error 1 DA0002: It appears that the file was collected without properly setting the environment variables with VSPerfCLREnv.cmd. Symbols for managed binaries may not resolve. C:\work\AbleAzure\Downloaded Profiling Logs\AbleAzureWeb24201441226PM\AbleWebRCore_0_(f1da3c).vsp 0 0
I checked the folder C:\work\AbleAzure\Downloaded Profiling Logs\AbleAzureWeb24201441226PM, it has all the PDB files in it.
I have no idea about the error "the file was collected without properly setting the environment variables", is it the Azure side or local? I don't see any place to set variable for Azure side.
Screenshot:
When you make the call to VSPerfReport to visualize your report, you need to specify the symbol locations:
https://msdn.microsoft.com/en-us/library/dd255404.aspx
They must match the versions etc.
Related
I am going to use Stimulsoft Reports.Wpf (Version: 2010.1.700 from 26 March 2010) to prepare some reports but unfortunately Sometimes when i want to create a new data source,an error is appeared saying :
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
An unhandled exception of type 'System.Reflection.ReflectionTypeLoadException' occurred in mscorlib.dll
last time that i saw this thing , i didn't do anything special about it.surprisingly it was fixed by itself.But this time it seems it is not going to work.
i have searched the internet 1000 of times but i didn't find anything useful.
what should i do to fix it ?
I Have this problem too. i install some font that was used in report. this problem solved.
or may be because of application cant find stimul soft reports needed dll files.
if reports call from another class library project.
if main exe file and class library report caller has different physical path in windows you have to copy stimulsoft report files into main exe file path and also into report caller dll path too.
I have a VS2012 solution, containing 10 projects, and suddenly, I can no longer publish my Services project to any folder.
When I try to publish to D:\temp, I get this error:
The expression "[System.IO.Path]::GetFullPath(obj\Release%25252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252528Prod%25252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252529\)" cannot be evaluated. The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets
Huh ?
VS2012 (with update 4) seems to have taken my configuration name "Release(Prod)" and completely messed it up, causing the GetFullPath to produce too long a path name.
How the heck can I fix this ?
Out of desperation, I tried to build and publish the same project in VS2013 - and it had the same error message.
One of my colleagues said he'd seen the same thing, but had fixed it by removing the spaces from his configuration name. I tried this, which is why my configuration name is now "Release(Prod)" rather than "Release (Prod)", but it made no difference.
I did also open the file which this error is suggesting is the cause of the error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets
..and noticed that there's something in there concerning the AnyCPU platform name. I have tried getting my Services project to use "AnyCPU" and "Any CPU" (depressed sigh) but neither seems to make any difference.
<PropertyGroup Condition=" '$(IntermediateOutputPath)' == '' ">
<IntermediateOutputPath Condition=" '$(PlatformName)' == 'AnyCPU' Or '$(PlatformName)' == ''">$(BaseIntermediateOutputPath)$(Configuration)\</IntermediateOutputPath>
. . .
</PropertyGroup>
Has anyone else seen this issue ?
(A little bit later..)
This is so odd (and frustrating).
My Solution has 5 configurations - the default Debug and Release ones, plus extra configurations for Test, PreProduction and Production environments.
If I select any of these three configurations containing brackets, I get this ridiculous "The specified path is too long" error, as VS2012 corrupts the pathname (as shown in my first screenshot above).
I can't help wondering... is this some kind of VS2012 bug, handling spaces or brackets in the configuration name ?
I can deploy to a path directly with (, (, )) in the Target Location on tyhe Connection tab when publishing to the file system (i.e. not building a path from the configuration name) - but that is not a solution to targeting different locations based on the Configuration.
If you want to keep special characters in the configuration name, but specify a path to the deployment folder that will not cause and issue this post might help: Visual Studio: How to properly build and specify the configurations and platforms for x64 and x86
Specifically play with the settings in here:
In the project properties page, select the various permutations of
Debug/Release and x86/x64 in the solution dropdowns. Make sure the
target processor is set correctly (it should be, but I found instances
when they were not, probably because of my previous attempts). Also,
set the output directory. That should be okay and automatic
(/bin/x86/Debug, etc.). If not, fix.
Looking at what is actually seems to be going on is also potentially useful:
Looking at the numbers inserted:
%25 is an encoded %,
%28 is an encoded (
%29 is an encoded )
Looking at the path:
obj\Release%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525***28***Prod%252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525252525***29***)
What I think is happening:
So that seems like a good clue that these are being URL or XML encoded. What appears to be happening is that the ( is being encoded as %28 and then the % is being recursively encoded as %25 - generating an infinite %252525252525252525....
A more interesting question is actually why it stops creating 25's from the %'s with this bug (both times it stops creating 25's at 214 characters including the % and the 28 / 29 - not a very interesting number).
Looking at the file C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets you reference - it makes sense that these strings are being encoded for XML. I would say this is definitely a bug... I have no suggestions for a fix.
Well, I'm going to accept Matthew's answer as the "Accepted Answer".
Thank you for your help.
This is a really odd problem though, and I'm amazed no one else has reported this elsewhere.
Summary of problem (in case Microsoft is interested, or if anyone tries to Google this issue in the coming years)
With a configuration name of "Release (Prod)", I could happily build my code, run it locally, but when I tried to publish it, even to a local drive, I'd get this message:
It's an odd exception, because the Build did create the "obj\Release (Prod)" folder, without any issues. It's just the Publish which seemed to be looking in the wrong place for it.
Following the advice given in this thread, today I attempted to create a new configuration, with the same settings, but without a space in the name: "Release(SecondProd)". Look what happens:
Interestingly, despite this error, it did create a new configuration with this name.
Anyway, I recreated a new configuration, called it ReleaseProduction, and it worked fine.
Of course, I needed to create new "web.config" Transformation for this name, as this doesn't get automatically copied when you create a new configuration based on an old one.
One last thought (just to confuse matters worse !)
When I posted this plea-for-help, the Services project in my Solution refused to publish to a local drive, but my web site would publish okay.
Today, two days since I last attempted a website Publish, I found that the website also now produces the same GetFullPath exception. Nothing's changed ! We use TFS, I have done a file compare with my project files today against two days ago, and they're identical !
It's a really bizarre bug in VS2012 & VS2013.
Btw, this solution & the projects in it, were originally a VS2010 project. They were upgraded to VS2012 over a year ago, but this Publish problem only started happening recently. I'm not sure if the problem is related to using upgraded VS projects.
Again, thanks for your help.
Now I have some Test, PreProd & Production configurations to recreate !
Maybe I'll grab a beer first..
Summarizing and completing Matthew's answer:
Cause: You have configurations with chars that require URI-encoding - in your case, '(' and ')'.
Workaround: Rename those configs.
What happens: Presumably web deploy URI-encodes the path, replacing % => %25, ( => %28, ) => %29. It does so over and over:
obj\Release(Prod)
obj\Release%28Prod%29
obj\Release%2528Prod%2529
obj\Release%252528Prod%252529
...
Until the path exceeds MAX_PATH=260.
I ran into the same thing and all though it does not resolve the issue I found that if I switch the solution configuration away from a build containing "(" or ")"
Then use the appropriate build in the publish dialog it will not error out.
Greetings people,
My Windows Store game has been released for more than three weeks now, and I started getting crash reports. I could download the TriageDump.dmp file and have it opened in Visual Studio 2012, but it did not help much, I am constantly getting "No Debugging Information" error message when I click on "Debug with Native Only":
Also, the tool-tip on my Dashboard shows no information of the crashing function (could "Unknown" here mean inlined function or lambda expressions in concurrent::task?):
I would like to believe that I have done everything the way it should be done, of course I may be wrong. Here are some additional information that might be helpful in finding the issue:
It uses DirectX and written purely in C++ (without C# or XAML)
Project setting: C++\General\Debug Information Format = Program Database (/Zi)
Project setting: Linker\Debugging\Generate Debug Info = Yes (/DEBUG)
The game is made up of two native modules: Labyrinth.App.exe and Labyrinth.Core.dll
The generated APPXUPLOAD contains both APPX and APPXSYM files
The APPXSYM file contains both Labyrinth.App.pdb and Labyrinth.Core.pdb
I'm on x64 development machine, and the triagedump.dmp is for x86
I did click on "Include public symbol files, if any, to enable crash analysis for the app" when generating APPXUPLOAD file:
Please let me know if you spotted the issue or suspected something that's wrong above. Thanks in advance for your help, guys! :)
The very same problem here. MS had that working in the past though.
Actually if you still have the .appxsym around you can easily extract the .pdb out of that. The appxsym is just a .zip file it seems.
You can load these pdbs then as symbols after loading the triagedump.dmp.
I am trying to figure out how to get the function of a module + offset of a thread. Similiar to how Process Explorer does in it's thread display. Example....
ntdll!TplsTimerSet+0x07c0
I can pull the start address with no problem, and I can also resolved the start address to the module. I can get the start address to show "ntdll.dll" plus the offset (startaddress - baseaddress), but not the function. So mine looks like this..
ntdll+3BC0C
I would like to locate which function of the ntdll dll the offset resides in. In this case the function is Tplstimerset. I know that I will have to calculate the diffence of the offset and the address of the function, but that should be easy. This code can be in C++ of Delphi/Pascal. Thanks in advanced.
In Process Explorer -> Options -> Configure Symbols, you can see symbols files are used in order to resolve functions.
These symbols are from Microsoft and both windbg and Visual Studio are using them when debugging.
If you started windbg and have loaded one executable file, type "x ntdll!*" to show all named functions of ntdll, the asterisk means it matches all.
I assume you need to get the addresses of named functions programmatically, you may need the .pdb file specification.
The Map file looks like:
0002:000442e4 00000118H .idata$2 DATA
0002:000443fc 00000014H .idata$3 DATA
0002:00044410 00000b7cH .idata$4 DATA
0002:00044f8c 0000512eH .idata$6 DATA
0002:0004a0ba 00000000H .edata DATA
The Crash info looks like:
Application Error : The instruction at "0x00458ae1" referenced memory at "0x00000074". The memory could not be "read".
I'm trying to get a stack dump on the next crash, but it seems to me this is a case where we trounced the stack, then did a return, which made us end up executing data.
I'm not entirely certain though because I read some articles like this: Under the Hood Article seems to indicate this is an area of imported method names
The data that an import library provides for an imported API is kept
in several sections whose names all begin with .idata (for instance,
.idata$4, .idata$5, and .idata$6). The .idata$5 section contains a
single DWORD that, when the executable loads, contains the address of
the imported function. The .idata$6 section (if present) contains the
name of the imported function. When loading the executable into
memory, the Win32 loader uses this string to call GetProcAddress on
the imported function effectively.
Without a stack backtrace I'm kind of stuck. Am I looking at this crash the wrong way?
Forget MAP files, better use PDB files. For this enable linker option /DEBUG - yes, even for Release builds. /DEBUG is linker option, _DEBUG is compiler option. Only _DEBUG controls the code, and any conditional compilation that source/headers have put against this.
Debug builds have optimizations disabled, _DEBUG macro enabled.
Release builds have optimizations enabled, _DEBUG macro disabled.
/DEBUG would just put debugging-information into the EXE/DLL, and wont affect anything else.
Coming back to problem, when crash occurs. Do NOT close the application when WER (Windows Error Reporting) says it crashed. Instead keep it there, goto Task Manager, goto Process tab, select that crashed/crashing process, and hit "Create Dump File". Dump file (full-dump) will be created in some local folder (the path will be shown by task-manager). You can now close the crashing application (the WER window).
Now copy this .DMP file into some safe location, preferably the folder having your original Release folder. Open it in Visual Studio or WinDbg. On VS, just hit F11/F10, and you will be shown call stack. If multiple threads are running (in your crashed application), launch "Threads" view, and see the only suspended thread, double click it and you'll find the crash location.
You must have correct PDBs along with all binaries, and absolutely same code to see Code, otherwise call stack wont be good.
To get more information about PDB and stuff, you can read this article.