I am currently trying to run scripts in Windbg (x64). However, the script I am trying to read exceeds 1MB and because of that, I am getting the error "Command file execution failed, Win32 error 0n87. The parameter is incorrect". Does anyone know how I could increase the limit in Windbg so that I could pass in scripts that are 10MB? Thanks!
Error as is shown in windbg:
$t2=00000000037b9db8
Address Gen Heap segment begin allocated size
00000000037b9db8 2 0 0000000003430000 0000000003431000 00000000043e8fb0 0x78(120)
Command file execution failed, Win32 error 0n87
"The parameter is incorrect."
Thanks for the help and sorry about not providing a lot of information. Apparently, the error seemed to occur when the file size exceeded 1MB and fixed-name aliases were used in the text file. As a workaround, normal aliases were used and the limitation was exceeded.
Related
So I got this error when added additional parameters. Now I've got 14 parameters, when I had 11 it worked fine. Is there any way to increase number of parameters powershell can send to jmeter ?
The number of arguments doesn't really matter, you might be suffering from CreateProcess API function parameter length limit which is 32767 characters.
Also it might be the case there is a problem with your filesystem, follow How To Fix File System Error -1073741819 in Windows 10 article for troubleshooting steps.
Also be aware that if you're passing multiple JMeter Properties via -J command-line arguments you can avoid this by putting the properties values into user.properties file or create your own .properties file and pass it to JMeter via -q command-line argument.
References:
Full list of command-line options
Apache JMeter Properties Customization Guide
Overriding Properties Via The Command Line
When I run sudo bpftool prog show I get the following output
39: socket_filter name bpfprog1 tag e29cda32ba011d7f gpl
loaded_at 2019-09-08T14:21:57+0200 uid 1000
xlated 248B jited 169B memlock 4096B map_ids 30
but If I try to get the program jitted output with the following command
sudo bpftool prog dump jited tag e29cda32ba011d7f
I get an error message, as reported below:
Error: can't get prog info (3): Bad address
QUESTION: what am I doing wrong? XD
You most certainly use a bpftool version compiled from Linux 4.20 or older, and hit a bug that was fixed in version 5.0. Update bpftool, and dumping programs by tags should work again.
As a side note, I usually use program IDs or pinned path, as I find it more useful to retrieve the program I want. Depending on your use case, tags might make sense, especially if you often load the same programs without changes (so you would be sure to keep the same tags) and do not have them pinned.
I'm trying to write a program to automate getting the call stack from crash dumps. It runs cdb.exe:
cdb.exe -i "{binaries path}" -y "{binaries path}" -srcpath "{source files path}" -z "{dmp file path}" -lines
I then feed some commands to CDB's standard input:
.symfix+ c:\\symcache
.ecxr
k
q
For many dumps this succeeds in printing the call stack, however some dumps do not work. The dumps that don't work output this error:
Unable to load image C:\Windows\System32\igdumd32.dll, Win32 error 0n2
*** ERROR: Module load completed but symbols could not be loaded for igdumd32.dll
However, Visual studio is able to figure out the call stack just fine. In the Visual Studio call stack, igdumd32.dll is at the bottom of the stack:
igdumd32.dll!0c70c570()
[Frames below may be incorrect and/or missing, no symbols loaded for igdumd32.dll]
I'm not sure if the symbol not loading is the problem or not, but I can't figure out why CDB can't get the call stack while Visual Studio can.
"Frames below may be incorrect and/or missing"
Sometimes this means what it says, annoyingly. I've no idea what VS does to get around it. So far the best I have for cdb is to, instead of k, run kd (the cdb command, not kd the kernel debugger program!) to get the raw stack data, then discard the junk lines between the useful ones.
You'll probably want to supply a number of lines (in hex) after kd to get enough output to contain the whole call stack.
e.g.
kd 200
Oh, this doesn't work for dumps generated from 64-bit processes because kd uses the wrong word size (afaict this is a bug). I'm currently looking for a way to work around this cleanly. For one thread you should be OK with something like:
dps #esp L200
This uses the esp register to access the stack, which is not portable but works for me. You may need a different register.
I'm attempting to debug a problem with a .NET service starting up. I'm following the tip here, but I'm having trouble getting symbols. This particularly causes a problem with debugging .NET exceptions, because WinDbg refuses to download the correct mscordawks.dll.
The error I'm getting is: WARNING: Network path disallowed: 'SRV*C:\WebSymbols*http://msdl.microsoft.com/download/symbols'
Either it's doing this because I'm debugging something in session 0, or because I'm running WinDbg elevated. How do I resolve this issue?
I'm not clear exactly what you're doing to trigger that error message. I'll assume it's a .sympath command or similar.
Check the output of .netsyms
It's undocumented in the help file, but I spotted it in this blog entry and it seems to work. Maybe it defaults to off under certain security settings. Pure guesswork I'm afraid, but so simple to try that I thought I'd suggest it. It may be that the security context you are using forces .netsyms to be 0. John's trick will then be able to get you symbols from the network which you can use without needing a network symbol path.
Windbg should use the mscordacwks.dll that is part of your .NET installation - you are debugging on the machine that is running the service and therefore windbg has the same .NET installation available to it as your service. There should be no need for windbg to hunt for it anywhere else. Hopefully all that is actually needed is your symbol path to be set "correctly", rather than real problems finding mscordacwks.dll. We can look at that later if it's needed.
Check the current status like this:
0:001> .netsyms
netsyms = don't care
Turning it off produces something similar to your error message:
0:001> .netsyms 0
netsyms = no
0:001> !sympath srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Network paths are disallowed, symbol server is not available.
Set your symbol path to a symbol tree on the local machine.
Symbol search path is: srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
WARNING: Network path disallowed: 'srv*C:\Symbols*http://msdl.microsoft.com/download/symbols'
Turning it on again allows network symbol search paths:
0:001> .netsyms 1
netsyms = yes
0:001> !sympath srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Sounds like you are trying to debug one of the system services that may cause a deadlock when the debugger attempts to access the network.
Take a minidump of the process .dump /mf c:\tmp\mydump.dmp, Attach a debugger to the dump, set your symbol path as above and then .reload. This will cache all the symbols you need.
Then you can live debug using the path srv*c:\WebSymbols
I am using windbg 6.12.0002.633 X86 on Windows Vista to analyze memory dumps for memory leaks.
I'm trying to use the command ``dumpheap -statto determine the quantities of objects in the heap.
Unfortunately, I'm getting the error*** ERROR: Symbol file could not be found. Defaulted to export symbols for SLC.dll. I have activated!sym noisyto show where the error comes from and the file SLC.pdb is just not available on the symbol server.
I have googled the file but haven't found such a downloadable file.
The last line in the log output says:Couldn't resolve error at "mpheap -stat"`.
I can't proceed debugging because I'm getting this error permanently.
Does anyone know where I can get a SLC.pdb file or another way to workaround this problem?
Writing
dumpheap -stat
Will result in
Couldn't resolve error at 'mpheap -stat'
However, this will work:
!dumpheap -stat
Note the exclamation mark !
Your error messages seems a little incomplete. The !dumpheap command is part of the SOS extension used to debug managed .NET code under WinDbg. Is that what you're trying to do? You should be able to use the command even without correct PDB files for all modules.
How did you load SOS? Can you use any other SOS commands?