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/
Related
I created some custom modules and Visual Studio drops the build files directly into the Kofax Bin directory. It is important to note that I'm using the modules as Winforms applications and Windows services (at the same time). The generated files are
MyModule.exe
MyModule.exe.config
MyModule.InstallLog
MyModule.InstallState
MyModule.pdb
I think that I only need the .exe file here. Of course I also add the .aex file to the directory to install the module. I also created two batch files to register the module on the local machine
RegAscEx.exe MyModule.aex
pause
and to install the module as a Windows service
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\installutil.exe" "%~dp0MyModule.exe"
pause
after running them as administrator I can delete them from the directory of course. I would like to know if it should be always fine to provide the .exe file, .aex file and the two batch files (which will be deleted later) only?
Basically correct. Some thoughts:
Build your application using the Release configuration (vs Debug). See discussion here.
PDB files usually are not needed in production. Still, you may want to generate and keep them if you plan on debugging in production.
The app.config file should be kept. Maybe you want to use application settings later on, and the supportedRuntime element is useful if someone wants to run your CM on a machine without that version of .NET framework being present (Windows will show a nice error message)
Keep the AEX file. This is required if someone wants to register your CM on another machine (e.g. deploying from DEV > TEST > PROD).
Include a single batch file that allows registering your CM on a new machine as well as adding it to Kofax Capture. Here's an example:
rem "C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" SmartCAP.CM.Sample.dll /codebase /tlb:SmartCAP.CM.Sample.tlb
rem RegAscSc.exe /f Register.inf
Another thing I usually include is the ability to install my CM in a similar fashion to native KC modules, for example: SmartCAP.CM.Sample.exe -install and SmartCAP.CM.Sample.exe -uninstall. Take a look at the AssemblyInstaller class for details.
I built MonoDevelop using these instructions. I compiled a console application with it and it's running on a Linux machine. I have noticed a memory leak and would like to track it and figure out what is being leaked.
According to these instructions, I must start the application with specific options in mono. At that point, the profilier will dump an MLPD file. I now have that file and would like to view it and see what's going on. I can not find this mprof-report program anywhere.
Has it been depricated? If so, how do we profile mono applications now? There isn't much about it online.
Thank you!
Has it been depricated?
No, it is a part of the Mono distribution and is a C-based program so it is a "native" binary and located in the "bin" directory along with mono, mono64 pedump, monograph, monodis, etc..
On MacOS these are located in:
file `which mprof-report`
/Library/Frameworks/Mono.framework/Versions/Current/Commands/mprof-report: Mach-O 64-bit executable x86_64
Man page:
NAME
mprof-report - report generator for Mono's log profiler
SYNOPSIS
mprof-report [option]... file.mlpd
DESCRIPTION
mprof-report is the report generator for Mono's log profiler. It reads the MLPD log
files produced by the log profiler and generates a report based on the options passed
to it. The output is based on individual reports which can be turned on or off. By
default, all reports are generated in summary form (i.e., non-verbose output).
mprof-report can read both normal and gzip(1)-compressed log files transparently.
For information about how to use the log profiler with a program, see the mono-pro-
filers(1) page, under the LOG PROFILER section.
~~~~~
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'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.
How do you debug your SharePoint 2007 code? Since SharePoint runs on a remote server, and I'm developing on a windows xp machine (with the necessary .dll files copied into my GAC), I haven't had much luck with finding easy ways to debug. Breakpoints don't work, etc.
The best way I've come up with is to enable page tracing in the web.config file, write trace messages throughout my code, and access trace.axd whenever I need to debug.
Does anyone have any better suggestions for debugging? Am I missing something?
From Andrew Connell's blog post on the subject:
Attaching the debugger to GAC'd
assemblies: "Why aren't my breakpoints
being hit?!?!" Ever been there? Me
too... what a PITA that is! What's
going on? Well, the assemblies are in
the GAC and the Visual Studio debugger
can't see the debugging symbols (aka:
*.pdb). Unless you've gone through the trouble of setting up a symbol store
where all your PDBs are going, you'll
need to put the debugging symbols in
the same location as the assembly. The
trick is finding the folder that
contains your DLL in the GAC.
The c:\windows\assembly folder is not
a real folder, it's a virtual folder.
To get to the REAL folder, do the
following:
Start ยป Run
%systemroot%\assembly\gac
[ENTER]
This will open the GAC folder.
Now, poke around until you find a
folder that looks like this (you might
need to jump up one folder and dive
into the MSIL folder): [assembly file
name -.DLL extention][assembly
version in format of
> #.#.#.#]__[assembly public key token].
When you find that folder, open it up
and you'll see your assembly. Copy the
PDB file to that folder and then
attach the debugger for some debugging
joy!
The best way (even the one endorsed by Microsoft) is to have a Windows 2003 Server with Sharepoint as your local Development machine.
See also this topic.
Don't put your assemblies into the GAC, put them in the bin directory - then you can use the VS remote debugger. Google creating .WSP files for distribution.
This also has the advantage that its easier to copy your new builds onto the server after compilation (post-build step) and its also the recommended way to increase security.
I recommend you develop on a Windows 2003 server with Sharepoint. It's a hassle to debug on a remote server.
You can do it in a virtual machine with VMWare or Virtual PC, if you have XP on your workstation.
Virtual machine is the only way to go. You don't want to dedicate a whole machine to dev (unless you have extras) and developing on your production server is just asking for trouble. I prefer VMWare, but there are others that work just as well.
Tracing works well as normal debugging isn't really an option.
What else I do is try to develop all the logic (the stuff that isn't SharePoint dependent) on just a regular asp.net site, then integrate it into SharePoint after it's tested.
Hope that makes sense.
Are you talking about developing web parts? Custom pages? Something else?