Two questions.
If I start task manager I can generate dump file either by right clicking on Applications Tab or right clicking on Process tab. Is there any difference in the dump file been generated from these tabs?
If I have a x86 application running on a x64 machine, can I use x64 task manager to generate process dump?
1) I don't know, but probably it's the same.
2) To dump 32-bit processes on 64 bits OS, 32-bit task manager must be used:
C:\Windows\SysWOW64\taskmgr.exe
Check the link Here
Related
If you look at this Youtube video, you can see that WinDbg is automatically executed when the process dies.
I've followed the tutorial and tried to do the same on my system. I first ran windbg -I, and then changed the HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Auto registry key to 0. Is there any other step that I'm missing?
Running the 64-bit version of WinDbg with -I command line option creates both 64 bit and 32 bit AeDebug entries. This can easily be proven with Process Monitor:
The 32-bit version of WinDbg creates 32 bit entries only. So, if you ran the 32 bit version, 64 bit programs are not handled. That's what I expect has happened. Another option would be that you ran it without administrative privileges and didn't read the failure message carefully.
In case you want both 32-bit and 64-bit crashes to be handled by WinDbg, run WinDbg -I for both versions. You'll find that WinDbg is smart enough to handle any order:
WinDbg32 will overwrite an existing entry created by WinDbg64 before
WinDbg64 will not overwrite an existing entry created by WinDbg32 before
Although WinDbg64 can debug 32 bit applications, it cannot load 32 bit extension DLLs, therefore you typically want both debuggers registered, not only the 64 bit version.
I can build and manually execute an EFI application in a UEFI environment. But, I'd like to have my application executed automatically at boot time.
Is there a way to tell the bootloader to do this or do I need to turn my application in to a driver to have it automatically executed? Is there maybe some entry in an FDF, DEC, DSC, or INF file I'm missing?
You can add a startup.nsh script file to your UEFI Shell boot drive that calls you application.
The following link should serve as a handy reference for working with scripts in the shell: UEFI Shells and Scripting. Look at section 3 (EFI Shell Scripts) specifically.
However, if you are actually building your own firmware, you can also look at creating a bootable EFI image and set your default boot option to this binary. This is most useful if you are including the binary as a part of your ROM, but it might be a little involved to set up the filesystem so that it is seen as a normal boot option.
Also, if you have complete access to your firmware source, you could also just load and call your binary from your BDS driver. I don't recommend this route, unless you are specifically aiming to create a standalone device that will never boot any other image.
#NicholasEmbry answer contain almost all what is needed, but I would like to clarify some things and add recent improvements in that area.
Adding UEFI application image to boot option is actually best known method when you don't have source code of your firmware, what is typical situation. You don't have to create any special bootable image it should be simple UEFI application image, what means that your INF should contain:
MODULE_TYPE = UEFI_APPLICATION
This option is not just for Option ROMs this is for all UEFI readable medium. For example you can create FAT32 partition on your storage (no matter if it is USB, HDD, SSD, etc. it just have to be readable by firmware) and place application image on this partition. Then boot to UEFI Shell and use bcfg command to affect your boot order.
bcfg command can be blocked by you BIOS vendor. In that situation please follow procedure from this post. This is booting rEFInd using USB stick. rEFInd contain bcfg tool and give you ability to use it.
How to use bcfg ?
All is described in help help bcfg -b. -b is UEFI pager. For those who like shortcuts, this command will display all boot options in system:
bcfg boot dump -v
You can add your application using command:
bcfg boot add <boot_pos> <path_to_uefi_image> <boot_order_name>
<boot_pos> - position in boot order. Note you usually want to put your application before OS. If there is no free boot option number before your OS you can of course move your OS one option down bcfg boot mv <old_pos> <new_pos> and then add your application image in between.
<path_to_uefi_image> - path to your UEFI image. This is UEFI readable path ie. fs0:\foobar.efi
<boot_order_name> - this is how you application will be visible in boot BIOS menu
I have received a mini dump file from our network support team. They complain that one of our sites on the production node causes high cpu usage.
The Windows server is x64 but the IIS App Pool is running in 32-bit mode. The network/support guys have used the default task manager to create the dump file so I assume the dump file must be a 64-bit one.
I downloaded WinDbg x64. Then I tried to follow the instruction given in the link below to find which part of the code can be problematic:
site
Although the dump file and WinDbg both are 64-bit, when I run "lmvm clr"command, the debugger shows this line:
Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
If I run this command:
.loadby sos clr
and then !pe command, I get "no export !pe found" (this happens with any other command such as !CLRStack).
If I get the 64-bit version of mscordacwks.dll and sos.dll, and copy them into the symbol folder, the libraries will be loaded but upon running !pe command I will get "Failed to load data access DLL, 0x80004005 error message!
What I am doing wrong? I asked the network team to send me the .dll files (sos.dll and mscordacwks.dll), I copied them to the symbols folder but nothing changed.
p.s. I have read all the similar posts but none helped.
Open the dump in a 32-bit debugger and run !wow64exts.sw. You should now be able to load SOS and run commands, though not all commands will work. This will help, but still the best solution is to gather the dump with a 32-bit tool.
I work part-time as a computer tech at the local high school. They needed a system to keep track of all the computers in the district (things like physical location of the machines and serial numbers for inventory), and told me to keep it on a budget. I sat down and wrote a little thousand-line script in Perl/Tk, which accesses a PostgreSQL database on the local server.
I also successfully wrote a launcher in C++ and compiled it with bcc32, so they can single-click the launcher executable to start the program without having to type anything into DOS. That works fine, and I can load this program myself by manually installing all the dependencies for it by hand.
I would like to build a setup program to automatically load the PostgreSQL application, Strawberry Perl, as well as the Tk, and DBD::Pg libraries, and finally, of course, the folder my application is stored in. It'd be nice to be able to create desktop shortcuts or start menu items too.
Has anyone had any success with software to generate .MSI files for Windows Installer on Windows XP and above? If so, what did you use, and did it cost any money? Alternatively, where do I need to begin reading in order to write my own setup program?
Nullsoft Scriptable Install System
I'm not sure if this will do everything you want, but have you looked at Win32::InstallShield?
I'm trying to deploy an application on Windows Server 2008 (SP2 x64) and Windows 7 (x64), using VS2005 Installer Project. The MSI version (I think) it the 2.0.
Everything works fine, except that some registry keys and some files are not copied on the install machine. The MSI system doesn't notify about nothing (and I don't know whether MSI logs its operations).
Are there incompatibilities between my MSI installer project and these new OSes? It seems to me that the OS protect itself for being modified in some part.
For example, I'm trying to set the registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\WinLogon\SpecialAccounts\UserList\User
but it is not created. In the same installer there are many other keys, which are created like expected (as they always did before on Windows XP and Windows Server 2003).
To provide another example, I'm trying to install the file
%SystemFolder%\oobe\info\backgrounds\backgroundDefault.jpg
(where %SystemFolder% is typically "C:\Windows\System32"), but the file is not copied at all!!!
What's going on?
I've found the backgroundDefault.jpg file is located in another directory: %SystemRoot%\SysWOW64\oobe\info.
But I've not specified nothing about a System (64 bit) folder. How can I copy the file in the right place?
First, regarding logging, you can request MSI to create a log file of its operations like this:
msiexec.exe -i my_msi_file.msi -l*vx logfile.txt
This will create a log file called logfile.txt.
Second, it sounds like you're creating a 32-bit MSI and running it in 64-bit Windows. There is nothing wrong with this, but be aware that Windows is using file system redirection. Windows has a separate SystemFolder and HKLM/SOFTWARE keys to host 32-bit applications. If you look in the Registry at HKLM/SOFTWARE you'll probably see a sub-key called Wow6432Node -- this is where 32-bit apps write their Registry data.