I'm a little confuse and maybe you can help me.
I've the mshtml.dll (version 8.0) and the Microsoft.mshtml.dll (version 7.0)
If I go to add a reference to my WPF project and try to add the mshtml.dll, it tells me that the reference has to be a valid assembly or com component. And that's right as I know I have to add a reference to Microsoft.mshtml.dll because it's mshtml.dll's wrapper, am I right?
Now, my mshtml.dll version is 8.0 and Microsoft.mshtml is 7.0.
Where can I found the 8.0 version of Microsoft.mshtml.dll?
If I add the 7.0 of the Microsoft.mshtml.dll it'll run the functions of the mshtml 8 dll?
Why are they different?
Thanks a lot for all, Jayson
Microsoft.mshtml is wrapped dll of mshtml.dll that's why you see the difference in version and this will be stored at( approximate location)
c:\Program Files\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\Office11\Microsoft.mshtml.dll
for ie-8 to ie-11 I am using Microsoft.mshtml 7.0.XXXX.XX dll without getting any problem.
but ie-11 not supports some of the functions of the dll.
let me know if you'll face any problem.
Yes, it will run your all functions without any problem except some functions
Related
While I am setting up MinGW-W64 (from sourceforge) exe file (for Windows 10) for C++, it shows a message that it was not downloaded correctly. My best guess is that I have a Anaconda/Jupyter setup having MinGW-W64, and it is making all the fuss. How to set it up for both C++ (VS Code / Code lite) and Python/Jupyter/Anaconda?
Make sure you don't mix versions in environment variables like PATH.
Maybe your download was bad?
Or you may have an antivirus software preventing the installation...
You could try a standalone MinGW-w64 build from https://winlibs.com/, which doesn't requite installation - just extract the archive and point VSCode to it.
I'm working with QT 5.4 and VTK 6.2 but I have some problems with QVTKWidgetPlugin.
Specifically, I can see the QVTKWidget option in QT Designer but I don't see it in QT Creator when I work with the file .ui.
I copied QVTKWidgetPlugin.dll in C:\Qt\5.4\msvc2013_64\bin and in C:\Qt\5.4\msvc2013_64\plugins\designer and QVTKWidgetPlugin.lib in C:\Qt\5.4\msvc2013_64\lib but I don't know what is wrong. Help please! Thanks! :)
P.S.: I work on Windows 7 x64
First, you need to make sure that you are compiling the plugin with the same settings used to compile Qt Creator, which may not be the same as the the ones you are using (Qt version, Visual Studio version, 32/64bits).
To see this information, in Qt Creator go to Help, and select About Qt Creator. It will tell you which settings were used to compile it. For example, I downloaded Qt5.6 for VS2015 64 bits, but the included Qt Creator (v3.6.1) was compiled using Qt5.6 with VS2013 32bits. As you can see, it is not necessarily compiled using the same toolset that you installed.
Try copying it in
\Qt\Qt5.4.1\Tools\QtCreator\bin\plugins\designer
and
\Qt\Qt5.4.1\Tools\QtCreator\lib\qtcreator\plugins
I want to load MSEC.dll in windbg Version 6.12.0002.633 X86.
when I use the command !load MSEC.dll
it says:
The call to LoadLibrary(MSEC.dll) failed, Win32 error 0n127
"The specified procedure could not be found."
Please check your debugger configuration and/or network access.
I changed the version to 6.11 and I also installed visual studio 12 run time with version 12 but it doesn't work!
Is there any way to handle this issue?
When we extract Bang Exploitable (!Exploitable) it creates 2 Folders:
x64
x86
Open the folder as per your Project Bit Size. Now inside that folder, you will get 2 another folders:
Release
Debug
Copy the files from release folder to the folder that contains the executable of windbg.
Sometimes you may also need to change the version of windbg for making it compatible with bang exploitable.
Download
http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools/dbg_x86.msi
I had the same issue (winxp sp3, windbg 6.12..., !exploitable 1.6). Installing CRT 11 runtime did not work for me. So, the only solution I've found is to use the older version of !exploitable (1.0.6), you can download it here: https://msecdbg.codeplex.com/releases/view/28935
I spent all morning trying to figure this out.
Codeplex was retired in 2021 and this assembly appears to be abandoned by MS so it's difficult to find information.
The site I'm linking to below indicates that you need the Visual C++ 2012 redistributable installed on the target machine to remove this issue.
The same site also statically linked the required files in the source code and rebuilt with VS2017. I downloaded the altered DLL and am now able to load msec.dll with the full path to the assembly in the command.
https://blog.didierstevens.com/2018/07/17/exploitable-crash-analyzer-statically-linked-crt/
Under Windows 7 x64, when I try to profile an x86 executable with the latest version of Dependency Walker (2.2.6000) the profiling process always hangs at a certain point. Most of the time the last DLL that is loaded is c:\windows\syswow64\URLMON.DLL, so it seems that something inside that DLL is causing a problem. Profiling the same executable on Windows 7 x86 works flawlessly.
I have googled quite extensively, but couldn't come up with a solution to the problem. One suggestion that I found was to uninstall IE 8 or IE 9 and replace it with IE 7, but this doesn't really help. The only effect that I can observe is that with IE 7 the profiling process hangs at a different DLL (iertutil.dll, if I remember correctly, also from the system's syswow64 folder).
So my question is: How can I get Dependency Walker to profile x86 applications on x64 Windows 7? Of course, it would also be nice to know why the problem exists in the first place :-)
Some final notes:
I am using the x86 version of Dependency Walker because I want to profile an x86 executable
Running Dependency Walker as administrator does not help
All profiling options marked as "may fail on WOW64" are disabled
The executable I am currently using as a test case to reproduce the problem is the Sumatra PDF viewer (download link) because it is a simple .exe that does not need installation
Updated instruction based on #Stone Free's comments
The download link you need has changed to:
https://www.microsoft.com/en-us/download/details.aspx?id=42273
Go down to the 2. Install WDK 10 section and select the download:
Locate and run the Wdk setup (wdksetup.exe) from stage 2, then choose the download option rather than install.
Once completed locate and run DownloadLocation\Windows Kits\10\WDK\Installers>"Windows Driver Kit-x86_en-us.msi"
Then you will find Dependency Walker at:
C:\Program Files (x86)\Windows Kits\10\Tools\x64\depends.exe for the 64 bit version
C:\Program Files (x86)\Windows Kits\10\Tools\x86\depends.exe for the 32 bit version
Which is Dependency Walker version 2.2.10011 built 2015-10-29
A handy tool is to use https://github.com/juntalis/depends-launcher which is a simple launcher for Dependency Walker that determines the platform (x86|x64|ia64) of an windows image (dll, exe, etc) and launches the appropriate version of depends.exe to view its dependencies. It's main purpose is for use in a context menu entry to easily view an image's dependencies.
The latest currently known version of Dependency Walker seems to be the 2.2.10011 from 2015-10-29 (links below).
It was deployed with some Windows Development Kit for Windows 10 but the version that it contained is not available anymore from the Microsoft Pages and all the newer Versions does not contain it anymore for unknown reason.
Maybe because also the latest versions have some Problems with the Dynamic-Link Library Redirection or other performance issues. (Using dependency walker under windows 10 seems to be a lot more slow and cumbersome than at previous windows versions - but still great tool for the job)
Following Versions are available:
2.2.10011 (2015-10-29)
unofficial available from this development blog - download at own risk
https://zzz.buzz/2017/05/18/download-dependency-walker/
2.2.9600 (2013-08-22)
available through the WDK 8.1
https://www.microsoft.com/en-us/download/details.aspx?id=42273
after installation present in C:\Program Files (x86)\Windows Kits\10\Tools\[Arch]\depends.exe
2.2.6000 (2006-10-28)
available from official authors website
http://www.dependencywalker.com/
Potential replacement:
For simple tasks the Github project lucasg/Dependencies may be worth to be checked out. But it currently does not support profiling a running app to debug broken runtime dependencies as depends.exe can do.
I've had to switch to using a GitHub project: Dependencies.
As of Windows 10 1809 (10.0.17763) I'm unable to run even depends.exe version 2.2.10011 included in 10.0.10586.0 WDK.
I ran into the same problem and I discovered it is fixed in the latest version of Dependency Walker. I compared 2.2.6000 versus 2.2.8288 and the problem exists in the former but not the latter. However, you will probably have to wait for the Windows 8 WDK to be released to the public in order to get the latest version.
I just installed wdk 7600.16385.1(from here) ,
and find windbg is missing even though I've chosen to install all components.
Is it officially removed from wdk now?
If that's the case,why?
WinDbg is shipped as a part of the Windows SDK. Please, check this link: http://msdn.microsoft.com/en-us/windows/hardware/gg463016.aspx. Install latest Windows SDK, and WinDbg can be found in C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows.
Mine was somehow installed in the directory C:\Program Files\Debugging Tools for Windows (x64)
It's contained in my (installed) copy of this exact WDK build (C:\WINDDK\7600.16385.1\Debuggers\windbg.exe). So no idea why it wouldn't be in yours.
Also, to my knowledge WinDbg was moved into the WDKs (and SDKs), with newer versions not being available through other channels, rather than out of them.