I installed retail symbols in D:\Symbols and given the path to my windbg.exe but it can't be loaded why?
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Connected to Windows 7 7601 x64 target at (Sat Jan 31 14:38:56.920 2015 (UTC + 3:30)), ptr64 TRUE
Symbol search path is: D:\Symbols
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe -
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.18247.amd64fre.win7sp1_gdr.130828-1532
Machine Name:
Kernel base = 0xfffff800`02c4b000 PsLoadedModuleList = 0xfffff800`02e8e6d0
Debug session time: Sat Jan 31 14:38:56.968 2015 (UTC + 3:30)
System Uptime: 0 days 0:43:25.215
The Debug Symbols that Microsoft provides are only usable for the RTM or Sp1 Version of Windows 7. When you install an Update, the PDBs no longer match.
Here you must point to the Symbol Server to download the new PDBs:
SRV*D:\Symbols*http://msdl.microsoft.com/download/symbols
It's easier if you have an internet connection to let windbg find and download the correct ones for you, whereby it will be cached locally:
.symfix;.reload
Will go and fetch the correct symbols from the MS symbol server at http://msdl.microsoft.com/download/symbols
if you download them yourself then you have to download the correct version matching your specific build and this is just too much of a headache to maintain so IMO it's just simpler to just let windbg handle this for you.
Related
We are trying to build ORAN- ODU-Low library (https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/build_prerequisite.html).
We have downloaded and built DPDK ,
#wget http://static.dpdk.org/rel/dpdk-18.08.tar.x
#tar -xf dpdk-18.08.tar.xz
#export RTE_TARGET=x86_64-native-linuxapp-icc
#export RTE_SDK=Intallation_DIR/dpdk-18.08
build DPDK:
#./usertools/dpdk-setup.sh
select [39] x86_64-native-linuxapp-icc
exit [62] Exit Script
'''
DPDK built successfully.
While building fapi library from odu, we see below errors:
In file included from /home/user/odu-low/phy/fapi_5g/source/include/nr5g_fapi_dpdk.h:28:0,from /home/user/odu-low/phy/fapi_5g/source/include/nr5g_fapi_args.h:23,from /home/user/odu-low/phy/fapi_5g/source/nr5g_fapi.c:32:
/home/user/odu-low/dpdk-18.08/include/dpdk/rte_memcpy.h:797:2: error: incompatible type for argument 2 of ‘_mm_storeu_si128’ MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/xmmintrin.h:1246:0,
from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/x86intrin.h:34,from /home/user/odu-low/dpdk-18.08/include/dpdk/rte_vect.h:29, from /home/user/odu-low/dpdk-18.08/include/dpdk/rte_memcpy.h:17, from /home/user/odu-low/phy/fapi_5g/source/include/nr5g_fapi_dpdk.h:28, from /home/user/odu-low/phy/fapi_5g/source/include/nr5g_fapi_args.h:23, from /home/user/odu-low/phy/fapi_5g/source/nr5g_fapi.c:32:
\/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/emmintrin.h:700:1: note: expected ‘__m128i’ but argument is of type ‘int’
_mm_storeu_si128 (__m128i *__P, __m128i __B)
We are building it on CentOS 7 - 3.10.0-1160.45.1.el7.x86_64 gcc version used: 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
Intel compiler icc was previously available as a part of intel system studio and required a license. The documentation on installing icc you refer seems to on O-RAN docs seems to be written during this period. Intel system studio now has been replaced by Intel oneAPI toolkits
Currently intel compilers(eg icc) are available for free without any license as a part of intel oneAPI HPC toolkit. You could easily download the toolkit for free by visiting the below link, and start using icc without issues.
https://www.intel.com/content/www/us/en/developer/tools/oneapi/hpc-toolkit-download.html
If you still need to download the older versions of icc you could try out by visiting the below link.
https://www.intel.com/content/www/us/en/developer/articles/guide/download-documentation-intel-system-studio-current-previous.html
It happened today when I suddenly noticed processes started getting slow on the computer. So I checked Task Manager to see what causes it.
I have waited a couple of minutes to see if it changes by keeping Visual Studio Code in idle state and then my computer dumps the memory in BSoD (blue screen of death).
After rebooting, I tried the same way to reproduce the state and within 20~30 minutes, it is up to 5 GB.
0 909 4452 c:\Users\arbaz\.vscode\extensions\ms-python.python-2018.12.1\languageServer.0.1.72\Microsoft.Python.LanguageServer.exe
What are the possible reasons causing this and how do I fix it?
Latest version:
Version: 1.30.0 (system setup)
Commit: c6e592b2b5770e40a98cb9c2715a8ef89aec3d74
Date: 2018-12-11T22:29:11.253Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
OS: Windows_NT x64 10.0.17134
Version: Code 1.30.0 (c6e592b2b5770e40a98cb9c2715a8ef89aec3d74, 2018-12-11T22:29:11.253Z)
OS Version: Windows_NT x64 10.0.17134
CPUs: AMD Ryzen 7 1700 Eight-Core Processor (16 x 3000)
Memory (System): 15.95 GB (3.87 GB free)
VM: 40%
Screen Reader: no
Process Argv: C:\Users\arbaz\AppData\Local\Temp\tasks.py
GPU Status: 2d_canvas: enabled
checker_imaging: disabled_off
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
rasterization: enabled
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
CPU % Mem MB PID Process
0 66 14620 code main
0 84 1092 gpu-process
0 51 6332 shared-process
0 199 8312 window (tasks.py - Visual Studio Code)
0 85 11724 extensionHost
0 2278 4452 c:\Users\arbaz\.vscode\extensions\ms-python.python-2018.12.1\languageServer.0.1.72\Microsoft.Python.LanguageServer.exe
0 5 11296 console-window-host (Windows internal process)
0 187 14320 window (Process Explorer)
Extensions:
Extension Author Version
(truncated)
-------------------------------------------------------
better-comments aar 2.0.3
vscode-django bat 0.17.0
unique-lines bib 1.0.0
python-extension-pack don 1.4.0
permute-lines ear 0.0.10
MagicPython mag 1.1.0
python ms- 2018.12.1
vscodeintellicode Vis 1.1.2
This issue is mostly caused by the extensions.
Try to monitor menu Help → Open Process Explorer for a certain period to see which process name is taking large memory.
Try uninstalling all extensions and removing all their junk from %USERPROFILE%\.vscode\extensions for windows.
This problem happened to me yesterday. I managed to fix the problem, but I am not sure if my solution applies to yours. I'm using Windows 10 and Visual Studio Code version 1.33.1.
The solution is to go to settings and enable jedi. The culprit that was consuming excessive RAM was Python language server. So, by enabling jedi, instead of using the Python language server for the intellisense function, jedi was used instead.
This is something like the question WinDbg: Version mismatch of dbghelp.dll when trying to attach to a process
However, I can't post to that question and the marked answer isn't really an answer and doesn't work for me.
I have a machine which I used to use for debugging crash dumps, but suddenly it fails to open any dumps, always reporting
dbghelp.dll has a version mismatch with the debugger
Microsoft (R) Windows Debugger Version 10.0.14321.1024 X86
Copyright (c) Microsoft Corporation. All rights reserved.
command line: '"C:\Program Files (x86)\Windows Kits\Debuggers\x86\windbg.exe" -c ".cmdtree c:\cmdtree.txt"
dbgeng: image 10.0.14321.1024, built Sat Jul 16 09:31:09 2016
[path: C:\Program Files (x86)\Windows Kits\Debuggers\x86\dbgeng.dll]
dbghelp: image 10.0.14321.1024, built Sat Jul 16 09:29:50 2016
[path: C:\Program Files (x86)\Windows Kits\Debuggers\x86\dbghelp.dll]
DIA version: 40116
So it's complaining of a mismatch, but there is no apparent mismatch.
The version of dbghelp and dbgeng in System32 and SysWOW64 is 6.1.7601.17514. But note that:
a) According to Microsoft page on DbgHelp, the version in Windows and WinDbg does not need to be (and probably shouldn't be) synced
b) I have another machine where I have installed 10.0.14321.1024 version of WinDbg, and it also has version 6.1.7601.17514 of dbghelp and dbgeng in Windows folders, and everything's working fine on that machine.
Any assistance appreciated.
This machine is basically bricked as far as analyzing crash dumps is concerned. I've tried reinstalling windbg, and installing different versions, still the same error occurs.
please help me:
I run nunit in in the windows console.
After more than 300 tests the programm hangs. I don't konw why.
C:\Projekte\Sochi2014_TP_testing\reporting>"NUnit 2.6"\bin\nunit-console.exe /la
bels /out=NUnitTestResult.txt /xml=NUnitTestResult.xml ..\bin\x86\Debug\Sochi201
4_TP_testing.dll
NUnit-Console version 2.6.0.12051
Copyright (C) 2002-20011 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.
Runtime Environment -
OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
CLR Version: 2.0.50727.5456 ( Net 3.5 )
ProcessModel: Default DomainUsage: Single
Execution Runtime: net-3.5
Log4Net not configured. Looked for file: C:\Projekte\Sochi2014_TP_testing\bin\x8
6\Debug\log4net.config
More details for my issue:
I use selenium and specflow.
Nunit hangs up in a "Scenario Outline". The previous test runs normal. The browser (FF 13) is open and runs normal when I use the mouse.
My guess is that you have a test with a deadlock. You can add a timeout to NUnit:
nunit-console /timeout=10000 (other options as before)
This adds a 10 second timeout to each test. Then you should be able to see which test times out, and work out where the problem is. The number of tests shouldn't be an issue - my Noda Time project has thousands of tests which run without a problem, and I'm sure that's far from the biggest project using NUnit...
this is the session of building exe file in matlab 7.1.
I think I have a problem with the compiler.
mbuild -setup
Please choose your compiler for building standalone MATLAB
applications: Would you like mbuild to locate installed compilers
[y]/n? y
Select a compiler:
[1] Microsoft Visual C++ 2008 Express in C:\Program Files (x86)\Microsoft Visual Studio 9.0
[0] None
Compiler: 1
Please verify your choices:
Compiler: Microsoft Visual C++ 2008 Express
Location: C:\Program Files (x86)\Microsoft Visual Studio 9.0
Are these correct [y]/n? y
*****************************************************************************
Error: Could not find the 64-bit compiler. This may indicate that the
"X64 Compilers and Tools" or the Microsoft Windows Software
Development Kit (SDK) is not installed. To build 64-bit binaries,
Microsoft Visual C++ 2008 Express Edition requires that these two
packages be properly installed.
*****************************************************************************
Trying to update options file: C:\Users\****\AppData\Roaming\MathWorks\MATLAB\R2010a\compopts.bat
From template: C:\PROGRA~1\MATLAB\R2010a\bin\win64\mbuildopts\msvc90freecompp.bat
Done . . .
>> mcc -m mainmain.m -o mainmain
Could not find the compiler "cl" on the DOS path.
Use mbuild -setup to configure your environment properly.
C:\PROGRA~1\MATLAB\R2010A\BIN\MEX.PL: Error: Unable to locate compiler.
Error: An error occurred while shelling out to mbuild (error code = 2).
Unable to build executable (specify the -v option for more information).
??? Error using ==> mcc
Error executing mcc, return status = 1 (0x1).
if the problem is with the compiler, how can I install another compiler?
I have windows 7 (64 bits) and I want that the exe file will work on windows operating system.
This is probably the result of one of two issues.
1) You don't have the Windows SDK installed (as indicated in the error message). According to this MathWorks page regarding supported compilers
Both Microsoft Visual Studio 2008 and Windows Software Development Kit (SDK) 6.1 must be installed. When installing Microsoft Visual Studio, you must choose "X64 Compilers and Tools" when installing Microsoft Visual Studio; this is not selected by default.
Now, keep in mind, this reference is for the most recent release of MATLAB, but I'm betting that this information is still relevant to your issue.
You can download the SDK here.
2) It's also possible that the compiler that you're using simply isn't supported for your release of MATLAB. See here for info on supported compilers for MATLAB 7.1.