I am fighting a bug which does not reproduce on my machine, but repeats every time on my client's machine. I've tried everything, and now I am looking for any debug data (or whatever) that IE8 leaves after a crash. Google and Microsoft searches gave me nothing. Where does Internet Explorer 8 store its crash dumps? It definetely sends something to Microsoft after a crash, how can I see it?
There is a post here that will show you how to generate a mini dump
http://www.vistax64.com/windows-updates/227276-mshtml-dll-internet-explorer-8-crash-3.html
To generate a minidump:
Download and install the "Debugging Tools" package
From the folder where you installed it, run WinDBG.exe as admin (right-click, "run as admin...").
Press F6, sort "by executable", find IEXPLORE.EXE, select, OK. (It's easier if you have only one instance of IEXPLORE running at this time.)
It'll spew out a whole bunch of numbers and eventually dump you on a prompt at the bottom of the page. Just type G and press enter. This attaches the debugger to the IEXPLORE process but then lets it "Go" and continue to do its thang.
Do whatever you need to do to repro the crash.
This time, a crash condition will cause the debugger to "break into" the IEXPLORE process and suspend all its actions. In other words, instead of seeing the same crash message you'll see the debugger take over and IEXPLORE will look like it's frozen.
Ignore all the spew again and wait for the prompt at the bottom of the WinDBG window, then type this:
.dump /m IE1.dmp
If you don't give it a full path, the IE1.dmp file will be created in the same folder where you installed the debugger package. If you zip up that minidump and upload it here, I or someone else may be able to dig more info out of it.
Related
Whenever I am debugging a new program by pressing the "Start without deubgging" button, sometimes it will open up a blank program like this:
I can not close these blank programs at all no matter how many times I try and close it, even with the task manager. And if I try to debug it again, it just opens up another blank program. The only way to fix this program is to either restart or shut my computer, but doing that tedious and I don't want to do that every time this happens. Is there a way to prevent this or at least close the blank programs? Thanks!
I loaded the minidump file into Visual Studio 2010, loaded all they symbols, both from my program folder and the Microsoft Symbol Server, then I chose "Debug Native Only" and the program ran up to where it crashed with the same error as displayed on the remote computer when the exe crashed.
Now an error "program.exe not found" and "program.exe was not found in the minidump. you need to load the binary in order to find the source for the current stack frame"
When I click on 'Browse and find program.exe', I select it but VS won't open it?
This dialog "Browse and find ..." tells us two important bits of information:
where it is looking by default (the full path)
the name of the file it attempts to load (exe or dll)
At the same time, it is silent about two more facts:
it is looking for a exename.pdb / dllname.pdb in the same directory
it checks for an exact (size and timestamp) match in the binary and does not bother to tell, the "Open" button just idles.
As soon as you pick the file it asks for, put it in the direcory it looks at, and add the corresponding pdb file, it will definitely work. Only be 100% sure the dll/exe/pdb combination you offer to the debugger is the very same one that was running at the time the minidump was created.
I know this is old, and the solution I found is dumb, but would help someone who is stuck. This issue is still seen on latest VS 2019.
So, the trick is to use the "Browse and find the *.dll" link, open the folder where your binary is located. Copy the binary and in the same window, paste it to a different location on your computer. Now click "Open". It should load the binary and show you the callstack!
Got help from this thread - https://social.msdn.microsoft.com/Forums/vstudio/en-US/81681f0f-42ac-469f-85bc-cb85b8771e60/cant-load-executable-to-go-with-crash-mini-dump?forum=vsdebug
I just started a new task at a "lower level" in the platform stack, and I'm getting started with windbg. I'm so far quite happy with the pure power of the debugger. However, I wish it would just save my session default, like the VS debugger does. What I want is that whenever I ".restart", or re-open windbg, it works just like I left it: same bp's, same sxe state, same files open in the same places, etc.
I know about "save workspace" which seems to do what I want, but it's manual, and I have to do it every time I make a change to the workspace state.
Is there a way to just have windbg do this automatically?
It should prompt the first time you close the session and ask you if you want to save your workspace, there is a checkbox like the image here.
If you click yes this time and the box 'Don't ask again in this WinDbg session' then it will automatically save your workspace, similarly you can also clear the workspaces if it's erroneously saved some breakpoints or paths that you are no longer interested.
Also you can set this in the options like so:
Microsoft NTDebugging Blog. Uncovering How Workspaces Work in WinDbg.
Is it possible to write a script to see which processes/programs are sending/receiving data over the internet in Windows XP? I have full administrator rights and I want to find a way to monitor data exchange on my machine without installing any additional software.
Step One: Windows XP
Open up the Run box by pressing the Windows key and R at the same time.
Put in CMD and press OK. The command prompt window will open up:
Step Two
In your open Command Prompt window, enter the following:
netstat -b 5 > activity.txt
and hit enter. (Note: to paste something into Command Prompt, you'll need to right click and click paste.)
If you forgot to run the prompt as an administrator (like I did in the screenshots above), just redo step one You can tell when it's running as administrator because instead of saying C:\Users\Username it says C:\Windows\system32.
If you've pasted the code right, a blinking cursor will... blink.
After a few minutes, press Ctrl+C. That'll stop the command.
Now type in command prompt activity.txt to open the log:
When you press Enter, your default text editor-probably Notepad-will open:
Now, scroll through the lists. You'll see that it's mostly your browser-but some times, there are programs like Google Talk's webcam program installed that call home even when you aren't using them.
Now that you've found any and all culprits that are programs accessing the internet (with and without your knowledge), you can either close them from the Task Manager or even uninstall them.
I am currently working on a program to immediately clear the list of previously-run-commands which appears in the Windows Start -> Run dialog. The procedure for clearing this list by removing the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU key is well documented; however, before these changes take effect, it seems to be necessary to do one of the following:
Restart the computer
Select Start -> Shut down, and then select Cancel.
Neither of these is ideal for the task I am trying to accomplish: #1 is extremely disruptive to the user, and #2 appears to require additional user interaction.
Does anyone know how to immediately (and programmatically) force a reload of this information without requiring any user interaction, while also minimizing disruption of the user's other activities? I would like for the user's Run history to be cleared out immediately after executing my program, without requiring any further action on their part (such as using the "Shut Down" -> "Cancel" trick in #2 above) or forcing a reboot.
Or, to approach the problem from a different angle: When clicking Start -> Shut Down -> Cancel, Windows Explorer reloads the RunMUI key. Is there a way to force a similar reload without having the user select Shut Down and then Cancel?
Things I have already tried:
Monitoring the explorer.exe status using procmon while selecting Shutdown and then Cancel. I see Explorer writing to the RunMRU key, but have not been able to determine what triggers this.
Numerous Google searches along the lines of "reload runmru without reboot". Most results still recommend method #1 above, although a few suggest #2.
Limited MSDN API examination. The RegFlushKey call appears promising, but I haven't ever used it before, so I don't know if it will apply to registry information cached by different processes.
Any suggestions or other information would be greatly appreciated.
Have you tried ccleaner?
http://www.ccleaner.com/
Not a full answer to your question, but I did find a third way to trigger the clearing of the run command from this article in PC Mag.
Killing explorer.exe and then restarting it will also clear the run list after the registry modification.
I have a nasty hack for you. Show the window programatically, hide it immediately (programatically) and click cancel on it (well, you guessed, programmatically).
You might try looking for the icon cache flush API, or other ones, I wouldn't be too suprised if they had side effects like the one you are looking for.
I've seen instances where it actually works, even the F5 key doesn't work? Try this, ctrl>alt>delete then go to task manager, processes tab...end explorer.exe. Then click on file new task and type explorer.exe, then check...does that work?
Windows XP
Right click on the taskbar
Properties menu option
Start Menu tab
Customize button
Programs pane
Clear List
Click on OK
This calls a Windows API function that refreshes the explorere.exe taskbar process and also clears the list (no need for registry edits).
As far as I know, it relies on the explorer.exe process that hosts the start menu/taskbar/desktop being closed and reopened. There is no "clean" way to do this that I am aware of.
If you really need to do this without user interaction, you need to close all explorer.exe processes and relaunch one.
Here's a rudimentary C# program to do that;
using System.Diagnostics;
Process[] procs = Process.GetProcessesByName("explorer");
foreach (Process proc in procs)
{
proc.Kill();
}
Process.Start("explorer.exe");
Note that this will close all "Windows Explorer" windows open, and may or may not open an additional "Windows Explorer" afterwards.
I just tested that on Windows XP 32bit, and it did indeed clear the Run command cache.
HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ RunMRU\