The Map file looks like:
0002:000442e4 00000118H .idata$2 DATA
0002:000443fc 00000014H .idata$3 DATA
0002:00044410 00000b7cH .idata$4 DATA
0002:00044f8c 0000512eH .idata$6 DATA
0002:0004a0ba 00000000H .edata DATA
The Crash info looks like:
Application Error : The instruction at "0x00458ae1" referenced memory at "0x00000074". The memory could not be "read".
I'm trying to get a stack dump on the next crash, but it seems to me this is a case where we trounced the stack, then did a return, which made us end up executing data.
I'm not entirely certain though because I read some articles like this: Under the Hood Article seems to indicate this is an area of imported method names
The data that an import library provides for an imported API is kept
in several sections whose names all begin with .idata (for instance,
.idata$4, .idata$5, and .idata$6). The .idata$5 section contains a
single DWORD that, when the executable loads, contains the address of
the imported function. The .idata$6 section (if present) contains the
name of the imported function. When loading the executable into
memory, the Win32 loader uses this string to call GetProcAddress on
the imported function effectively.
Without a stack backtrace I'm kind of stuck. Am I looking at this crash the wrong way?
Forget MAP files, better use PDB files. For this enable linker option /DEBUG - yes, even for Release builds. /DEBUG is linker option, _DEBUG is compiler option. Only _DEBUG controls the code, and any conditional compilation that source/headers have put against this.
Debug builds have optimizations disabled, _DEBUG macro enabled.
Release builds have optimizations enabled, _DEBUG macro disabled.
/DEBUG would just put debugging-information into the EXE/DLL, and wont affect anything else.
Coming back to problem, when crash occurs. Do NOT close the application when WER (Windows Error Reporting) says it crashed. Instead keep it there, goto Task Manager, goto Process tab, select that crashed/crashing process, and hit "Create Dump File". Dump file (full-dump) will be created in some local folder (the path will be shown by task-manager). You can now close the crashing application (the WER window).
Now copy this .DMP file into some safe location, preferably the folder having your original Release folder. Open it in Visual Studio or WinDbg. On VS, just hit F11/F10, and you will be shown call stack. If multiple threads are running (in your crashed application), launch "Threads" view, and see the only suspended thread, double click it and you'll find the crash location.
You must have correct PDBs along with all binaries, and absolutely same code to see Code, otherwise call stack wont be good.
To get more information about PDB and stuff, you can read this article.
Related
I got the really common Automation Error when I ran a VB6 application for the second time. However, the code worked fine under VB6 debugging mode. After I compiled the code and run some function for the second time, I would encounter the Automation Error 2147417848 - The object invoked has disconnected from its clients.
Then I debugged the application thru Visual Studio and got the following exception error:
Unhandled exception at 0x76B33E8D (oleaut32.dll) in vb6_2_12_2015.exe: 0xC0000005: Access violation reading location 0x01289B5C.
Is it because of something wrong with my dll registration?
The message means your program is accessing memory (ie a variable or object) that has been freed or never existed (usually because creation failed and the programmer didn't check). A memory address under 64K indicates a failed allocation.
To start with, compile your program without optimisations and with debugging info. When you crash do a stack trace which will list functions and parameters.
You can also start in a debugger.
windbg or ntsd (ntsd is a console program and maybe installed). Both are also from Debugging Tools For Windows.
Download and install Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
Start Windbg. File menu - Symbol File Path and enter
srv*C:\symbols*http://msdl.microsoft.com/download/symbols
then
windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat
You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.
Type lm to list loaded modules, x *!* to list the symbols and bp symbolname to set a breakpoint
da displays the ascii data found at that address
dda displaysthe value of the pointer
kv 10 displays last 10 stack frames
lm list modules
x *!* list all functions in all modules
p Step
!sysinfo machineid
If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than seperate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.
Also CoClassSyms (microsoft.com/msj/0399/hood/hood0399.aspx) can make symbols from type libraries.
.
I am using an xla file to run my vba-code in excel. I have many templates, which use this xla file. Is there any way to find which template runs(opens) the xla file from xla.
I have used:
ThisWorkbook.FullName
but it returns the name of the xla file and not the name of the template
I don't think there is a straightforward way for a Function or a Sub to find out who's calling it (because the call/stack tracing is not available programatically to VBA).
You could do your own tracing, by implementing some push and pop operations on a custom-made stack globally accessible in your .xla, for example. When a function is called, it pushes its filename+module+name to the stack, and when it ends it pops that information from the stack.
But then again, it depends on the "benevolence" of the calling function (e.g. the one from the file that references your .xla file) to use your tracing convention. Also, it might make your code more brittle. And also, it could make it worse actually, if you don't handle every exception that might break the execution of your functions/subs.
See also this (last section): http://www.cpearson.com/excel/DebuggingVBA.aspx
Tried a lot different things, but what should be a simple thing never works for me. VSP file downloaded, but doesn't show my function names, only hex codes. It does give an error:
Error 1 DA0002: It appears that the file was collected without properly setting the environment variables with VSPerfCLREnv.cmd. Symbols for managed binaries may not resolve. C:\work\AbleAzure\Downloaded Profiling Logs\AbleAzureWeb24201441226PM\AbleWebRCore_0_(f1da3c).vsp 0 0
I checked the folder C:\work\AbleAzure\Downloaded Profiling Logs\AbleAzureWeb24201441226PM, it has all the PDB files in it.
I have no idea about the error "the file was collected without properly setting the environment variables", is it the Azure side or local? I don't see any place to set variable for Azure side.
Screenshot:
When you make the call to VSPerfReport to visualize your report, you need to specify the symbol locations:
https://msdn.microsoft.com/en-us/library/dd255404.aspx
They must match the versions etc.
I am trying to figure out how to get the function of a module + offset of a thread. Similiar to how Process Explorer does in it's thread display. Example....
ntdll!TplsTimerSet+0x07c0
I can pull the start address with no problem, and I can also resolved the start address to the module. I can get the start address to show "ntdll.dll" plus the offset (startaddress - baseaddress), but not the function. So mine looks like this..
ntdll+3BC0C
I would like to locate which function of the ntdll dll the offset resides in. In this case the function is Tplstimerset. I know that I will have to calculate the diffence of the offset and the address of the function, but that should be easy. This code can be in C++ of Delphi/Pascal. Thanks in advanced.
In Process Explorer -> Options -> Configure Symbols, you can see symbols files are used in order to resolve functions.
These symbols are from Microsoft and both windbg and Visual Studio are using them when debugging.
If you started windbg and have loaded one executable file, type "x ntdll!*" to show all named functions of ntdll, the asterisk means it matches all.
I assume you need to get the addresses of named functions programmatically, you may need the .pdb file specification.
I have an MFC App which fires up a separate thread for downloading some files via cURL. At the start it downloads a text file with file sizes and last write times. Then it checks the files on disk and queues it for downloading if it has different values.. The problem is; the CreateFile call in the thread arbitrarily returns INVALID_HANDLE_VALUE. I always do CloseHandle() after a successful CreateFile(). The failing files are just random. Sometimes a file in the root dir, another time a file in a nested directory. The problem is not related to localization or directory/file names since sometimes all checks pass but sometimes don't. GetLastError() return 2 or 3 on occasion which are "File not found" / "Path not found" respectively.
When I put the function checking the file write times and size straight into the OnInitDialog() function, everything works. This smells like a multithreading issue but I double-checked everything from memory allocations to file handles.
The same code works in a console application also in a separate thread.
The platform is Win7 64bit.
Linking statically to the runtime and MFC.
in my case GetCurrentDirectory() returned the system32 path after some time so my code failed because of credentials. I fixed the issue by determining file paths manually (getting the exe path at the start and use it from there on...) . Make sure you are not trying to write to/read from a privileged location on disk. Check your paths.