I've indexed a PDB file with source server information. The pdbstr utility dumps out the following srcsrv stream:
SRCSRV: ini ------------------------------------------------
VERSION=2
INDEXVERSION=2
VERCTRL=http
SRCSRV: variables ------------------------------------------
HGSERVER=http://repository-srv
SRCSRVVERCTRL=http
REPONAME=clr_foundations
HTTP_EXTRACT_TARGET=%hgserver%/%reponame%/raw-file/%var3%/%var2%/%fnfile%(%var1%)
SRCSRVTRG=%http_extract_target%
SRCSRVCMD=
SRCSRV: source files ---------------------------------------
C:\workspace\clr_foundations_build\clr_foundations\Tests\native_rpc_server\main.cpp*Tests\native_rpc_server*776954c6675e
SRCSRV: end ------------------------------------------------
As you see, this instructs the debugger to use the HTTP gateway to our Mercurial server. When using this PDB file with WinDbg, the debugger prompts me for basic HTTP credentials to access repository-srv and successfully displays the source file. (The same URL also works in a browser window, or with a command-line tool like curl.)
However, when using this PDB file with Visual Studio 2012 (and having enabled source server supports in Tools > Options > Debugging), the debugger does not resolve the file from the source server, prompts me to point to a file on disk, and displays the following error in the output window:
SRCSRV: Source server cannot retrieve the source code for file 'c:\workspace\clr_foundations_build\clr_foundations\tests\native_rpc_server\main.cpp' in module 'C:\workspace\clr_foundations_build\clr_foundations\Tests\native_rpc_server\Win32\Debug\native_rpc_server.exe'.
There is no additional error information so I am at loss how to further diagnose this. Is there anything else I could do to get more detailed error information, or alternatively another approach I should take?
I don't know if you have solved the problem.
I had a same problem the last days and could fix it by specifying a Cache directory under Tools/Options/Debugging/Symbols. I think VS needs to know where to save downloaded source files.
You need to run Visual Studio 2012 elevated, then it will work.
Related
In Visual Studio Code, as you might know, there are many options under File:
Open file
Open folder
Open workspace
Add folder to workspace
etc.
Could anyone please tell me the differences and benefits to choosing any of these over others? VS Code clearly sits gently on top of the File system, and is not heavily configured (say like, VS 2017, NetBeans, Eclipse, etc.) - it is of course closer to its sibling, Atom.
But I'm not entirely sure the advantages or recommendations related to, for example, Add Folder to Workspace vs just Open Folder, saving the workspace (or not), etc.
Any help would be appreciated.
Thanks a ton!
-J
1. Firstly open file is just the option to edit or open a file.
2. Secondly opening a folder is the option to import your project directory in the editor.
3. Then comes the workspace option which is quite similar to the open folder option with the difference that every workspace has its custom working settings.
VS Code provides two different scopes for settings:
User Settings - Settings that apply globally to any instance of VS Code you open.
Workspace Settings - Settings stored inside your workspace and only apply when the workspace is opened.
Workspace settings override user settings.
For more details you can refer to VS code settings (docs)
I used to read windowsupdate.log file to troubleshoot issues on Windows Update process. In that file I could check when cab file was not signed or WUA was not running or not properly installed or if the system was using the Windows Update process or a third party tool. But starting with Windows 2016 the windowsupdate.log file was replaced by ETW (Event Tracing for Windows) as commented in this link http://go.microsoft.com/fwlink/?LinkId=518345
The link also explains how to use a PowerShell script to convert ETW file in readable files. But the point is that even these "readable files" I cannot find how to extract the same information I got in the old windowsupdate.log file. The resulting file only provides a list of GUID files that I suppose the installed files.
I'm doing a school coding project using Android Studio with Google Drive to store my app files. Google Drive is generating these desktop.ini files. Every time I delete or modify them, they are regenerated, even when I shut down Google Drive. How can I fix this? I cannot run or debug my project with this error.
As a matter of fact the desktop.ini file is created only in Google Drive folder. So you can't blame it on Windows. If it is Windows, then the file should be everywhere. Also, if you open the desktop.ini in Notepad you will see the following lines:
[.ShellClassInfo]
InfoTip=This folder is shared online.
IconFile=C:\Program Files\Google\Drive\googledrivesync.exe
IconIndex=16
See InfoTip and IconFile. There is no way Windows would be doing this.
I got my solution：
1）Open ini file's Property Dialog
2）Hide this file in System File way，use this cmd：attrib +h +s "D:\Google Docs\desktop.ini" /s /d
3）Deny all Access Privilage in Property Dialog，like this：
4）Just refresh folder！
Desktop.ini files are generated by Windows, not Google Drive. When you open a folder in Windows, it creates a desktop.ini file. The desktop.ini file stores the view settings for that folder.
As to why you are getting build errors in Android Studio simply because this file exists, I can't answer at the moment. I have successfully built many Android projects in Android Studio with that file in the folder.
I am trying to publish an application with VS2012 and when i try and make the package i get an error that access to the path is denied. I have checked and my user has full control and verified the path.
VS is trying to access .pubmxl file that is there.
I have also tried running VS2012 as administrator.
I had this same issue (VS2012: Access to path is denied when executing publish) and found a way to allow Visual Studio access to the file.
If you open the pubxml file in Visual Studio, make an edit, and save the file, Visual Studio is able to successfully publish using that file. Hope this works for you too.
Creating a new profile worked for me. I got this error when I tried to change the path of an existing profile, and Unfortunately I could not find the original pubxml file, otherwise I would have simply copied it to the new location and followed advice #1 (edit the file in location from VS2012). It's easy enough to create a new profile as there aren't many settings anyway.
I have experienced this issue and I noticed that the files were "Read-Only". Selecting the files and removing the "Read-Only" attribute allowed me to Publish successfully.
Sounds like TFS feature rocks again. Remove publish profile from local repo and get latest version afterwards, then you should be fine.
I had the same problem and fixed it by removing my Publish profile and creating a new one.
I have an VC++ exe in Remote (customer end).They are repoterd that crashing has occurred.How to identify the problem cause without using the source code and i want to use only .pdb file to analyse .Please tell me how to use .pdb file for debugging.
As a first step get the crash dump using WIndbg or DebugDiag
Please check with customer whether it is ok to install any of the above mentioned tools and get the dump.
Ask thecustomer to send the dump for the crash of the particular exe that you are saying is crashing.
Next analyse the dump file using windbg or debugdiag in your machine using the right pdb.
please tell if any more information is required.
Minimal help for analysing the dump will be given in the help files of windbg or debugdiag itself.
You can also open dump and mini dump files in Visual Studio as well (Open them with Open Project... and point at the dmp file.) If you have pdb files that is properly indexed, you can often get a proper call stack that will point you to where the error occurred.
You should also check out Windows Error Reporting. If this is commercially available software, I suggest you sign your binary files before deployment. You can then ask the customers to submit errors to Microsoft through their standard Windows Error Reporting Service.
On the other side, you can sign up on their WER portal and identity yourself with the certificate you signed the binaries with. From the portal you can get error statistics and download specific dump files.
If the software runs in an isolated environment - a private domain, you can push out a custom global policy in your active directory, that configures WER to submit dump files to a specific Windows share in your domain where the developers can collect them.
Hope this helps,
--larsw
Here are the initial steps to follow:
On the customer machine:
a. install windbg. this can be downloaded from the microsoft website.
b. once installed register the just in time debugger [windbg -l].
c. execute the application which is causing the crash.
d. the windbg will automatically open up when there is a crash.
e. save the dump file.
On your machine:
a. open the crash dump using windbg.
b. set the pdb files and source files on your machine in windbg.
c. You can generate pdb's using the project properties in visual studio.
More details I found in: http://kmdarshan.com/blog/2011/06/29/windows-debugging-using-windbg/