After failing to get DebugDiag to analyse crash-dump files it was suggested that I try using WinDbg instead.
The crash-dump files have been created on a Windows Server 2016 box, running my ASP.Net 4.5.2 web application on IIS-10. My ASP.Net web application contains several 3rd party components, with their individual DLLs.
I have copied the crash-dump files onto my Windows 10 development machine, and am running WinDbg locally instead of on the server.
The problem is... when I run !analyze -v in WinDbg on any of the crash-dump files, it effectively hangs while "Downloading file xxx.DLL" (xxx.DLL being the name of just one of the 3rd party component DLLs), and eventually cancels itself after a period of time.
I'm running WinDbg on the same machine that I built the website on in the first place... so is there a way of telling WinDbg that it can find the DLL in a particular location on the local machine?
I obviously don't have a .pdb file for any of the 3rd party components, and so I'm not bothered about it loading symbols for those DLLs... but either I somehow tell it to ignore those particular DLLs, or I tell it how to find them locally.
Can anybody point me in the right direction?
You don't have to analyze the dump file with !analyze -v.
If you need to load dll, then .load D:.... is enough.
To maunal analyze a dump file.
Please run .loadb sos clr to load debug module. If the crash server and your machine run different version of .net framework. Then you need to load sos.dll manually.
When you need to debug .net application in IIS, !mex extension is recommened.
https://www.microsoft.com/en-us/download/details.aspx?id=53304
You can load mex.dll via .load c:\.....\mex.dll
!mex.aspxpages can show all requests inside the process and their process
!mex.mthreads show the status of all threads
!mex.clrstack2 will show all exceptions and mananaged call stack in specific thread.
1.You can use ~* k to load the full call stack in all threads and !mex.mthreads check status.
Then you may find something like KERNELBASE!RaiseException in specific thread
2.Then go to this thread via threadid~ like 12~
3.Run !mex.clrstack2 and it will show the crash exception
Basically, no, you cannot speed up the process of loading symbols for DLLs where you don't have symbols. IMHO, the only way of speeding up the symbol process would be to disable the HTTP server, so that symbols are only searched on your local disk.
See also: How to set up symbols in WinDbg if you have not done this often.
Getting a HTTP 404 for those files should not take very long. However, it tries various file endings and pointers etc. Sometimes Microsoft servers are slow. Also, having a lot of 3rd party DLLs may sum up of course. That can be pretty anoying.
I'll start by saying I don't 100% understand everything I had to do, but here are the step I took to discover where the stackoverflow issue was in my application...
The majority of the information came from this blog.
On the server I added the following registry settings to create the crash dump files...
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe]
"DumpCount"=dword:00000005
"DumpFolder"=hex(2):43,00,3a,00,5c,00,43,00,72,00,61,00,73,00,68,00,44,00,75,\
00,6d,00,70,00,73,00,5c,00,00,00
(The DumpCount is the number of files to store before it starts overwriting old ones - DumpFolder is where the files are to be saved, is a REG_EXPAND_SZ and in my case represents C:\CrashDumps\)
Waited for crashes to happen
Copied the crash files into a directory on my local machine called C:\WinDbg\CrashDumps\
Create another directory called C:\WinDbg\Symbols, into which I placed...
clr.dll (from the server, taken from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\)
sos.dll (from the server, taken from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\)
all .dll and .pdb files from my local development environment, including third party component .dll files
Installed WinDbg via Windows Store on my Windows 10 development machine
Ran windbgx -y c:\windbg\symbols via Run command (for some reason it's windbgx on my machine but maybe that's because it's via the Store rather than manual download)
In the file menu Open dump file and select one of the dump files in C:\WinDbg\CrashDumps
Ran the following commands...
.symfix
.reload
.load c:\windbg\symbols\sos.dll (see note 1 below)
!clrstack (see note 2 below)
Although this didn't give me all the information I expected, what it did show was that one of my 3rd party components was 100% to blame for the stackoverflow exception.
Note 1 - Lots of places I read said that .loadby sos clr should be used, but that just gave me The call to LoadLibrary(C:\ProgramData\Dbg\sym\clr.dll\5E7D1F3B9eb000\sos.dll) failed and I couldn't figure out how to fix it... so instead I've used .load c:\windbg\symbols\sos.dll.
Note 2 - The !clrstack command worked because WinDbg appeared to pre-select the thread that had the exception. The other option is to use ~*e !clrstack which will show you call stacks for ALL threads.
After going through a windows 10 re-installation due to a windows update crashing my laptop, I was left with re-installing many applications. One of them being node.js. When I tried to install it through the windows installer, I kept getting 'setup wizard ended prematurely because of an error message'. I am not sure what the problem is. I used x64 version which is what my OS is and there is no nodejs folder in program files. When I logged the installation this message popped in a lot of the lines has no eligible binary patches. Before the no eligible lines there were error logs such as:
'WixSchedInternetShortcuts: Error 0x8007000d: failed to add temporary row, dberr: 1, err: Directory_'
'WixSchedInternetShortcuts: Folder 'ApplicationProgramsFolder' already exists in the CreateFolder table; the above error is harmless'
If that is not enough information please advice me on how to send the full logs without spamming huge text in the thread. Thank you.
The MSI log file:
https://gist.github.com/luki2000/ab00476127d54aaf610d8bda84d40a64
Maybe try to search the log for "value 3" as explained by Rob Mensching in his blog. Doing so will find the locations in the log file that describe errors of significance.
Many people use dropbox, gdisk or similar to post logs. Some put it on github (just a sample log for OP, leaving in for reference). Check that last link, is that the same problem you see perhaps? (search for "value 3" as explained above - without the quotes of course). Looks like there is an error creating an Internet shortcut. Perhaps that is a Windows 10 problem? I will take a quick look.
I am betting Bob Arnson knows what this problem is outright. He will probably give us the real answer, see below for my workaround.
The correct thing to do overall, would probably be to communicate the problem back to the Node.js guys so they can fix the problem once and for all.
UPDATE: Maybe see if this answer helps you: node.js installer failing with 'CAQuietExec Failed' and 1603 error code on Windows 7. Essentially un-check Event tracing(ETW) in the setup's feature dialog - or you can try to launch the MSI from an elevated command prompt.
UPDATE: There seem to be two Internet shortcuts configured for this MSI in the WixInternetShortcut table. I would just create a transform to remove these two shortcuts and try a reinstall. If you feel bold and fearless and like to break the law, you can delete the two rows from the table and just save directly to the MSI itself. This is never the right thing to do if you are a deployment specialists. The original MSI is sacred, but if this is for your own system and you need to get something done, that would work. Then you just install the MSI direct afterwards. Otherwise you can install the transform after creating it with a simple command line:
msiexec.exe /i node-v8.11.2-x64.msi TRANSFORMS="C:\MyTransform"
You can create the transform using Orca, InstEd or SuperOrca or any commercial tool that supports creating transforms.
In case you don't know, transforms are little database fragments that are applied to the original MSI (which is also a database under the hood). After the transform is applied the in-memory version of the MSI is the MSI + the changes from the transform.
I am trying find a problem with my program that is hooking into a game. This is
vc++. Basically I launch the program and then hook into it using SDL. When I run the code from VS2010, all works fine. But when I try to run from command prompt, my program can launch the game, but after that the game crashes immediately.
I was viewing windows event logs, and it appears that there is an access violation. 0xc000005
How can I log any further details about the program that crashes? I tried "procdump" but that is not useful as I cannot INDIRECTLY target the hooked game from console. Rather it can only target my application that hooks.
Anyway of getting detailed dumps is highly appreciated in this case.
Thanks!
You can perform postmortem debugging by using a combination of the WER registry keys/values to trap any dump that is produced. I’ve used this method to prevent the WER system from collecting the dump file (.dmp). I’ve also written about this in another similar post. To accomplish this, you will need to create a registry key under
Software\Microsoft\Windows\Windows Error Reporting
if one does not already exist. The key should be
LocalDumps\your application.exe
Once that’s done, modify these keys/values to meet your needs:
DumpCount, DumpFolder, DumpType
You’ll need Administrator rights to create and modify the keys, and, you should reset everything you’ve modified when you’re done debugging.
Annoyingly, when developing in MSVC2010, my EXE will not link (ie cannot emit output file) because the application experience service in Windows 7 has stopped.
I've no idea how these two things can be related, but i've been "fixing" it my manually restarting the process in the Windows service manager. Then i can link. At a random time later it will happen again. the process is set to automatic by default.
i've had enough of this madness. does anyone have any ideas? thanks.
Please try this: http://gauravpandey.com/wordpress/?p=291 it should work. it has atleast worked for me though I have not really understood the relationship between the two issues.
I'm using liferay portal community edition 6.1-
I'm trying to export a portal in order to move the content to another intance of liferay. however, when trying to export the portal content the export fails with message 'Your request failed to complete."
When looking at log files, there is no sign of anything going wrong.
Could someone please explain to me what can possibly be wrong, and from where should I get the information for what is failing on server?
Marko
I've been digging into similar issues with the LAR importing/exporting system myself. There isn't much logging in that code unfortunately. I ended up enabling remote debugging in the server's JVM and stepping through the problematic tasks using the Eclipse debugger.
One of the main issues I've had with Liferay is that it swallows detailed exceptions, doesn't log them, and waters them down into very generic error messages by the time they're displayed to you in the UI. Using the debugger really helps because you can often see the original exception without having to dig too deeply into the code.
How's your free disk space looking on the server? I believe Liferay saves the LAR to a temp file as it works on it (at least, it does as part of the publishing process). On our test site, with only ten pages and almost no content, that temp file is still 3.5M. If your site is really big you might just be running out of space.