How can I debug the dynamic library conveniently and quickly in Visual Studio 2022?
If Xenos injection is used, nothing is output (random process).
If it passes through the attached process, it does not enter any breakpoint (random process).
#include "pch.h"
#include <iostream>
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
std::system("ls>1.txt");
case DLL_PROCESS_ATTACH:
OutputDebugString(TEXT("INterdll"));
break;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
In Visual Studio 2022 you can debug your own library by attaching to the application which uses your library. When I usually develop C++ libraries, I create a separate project which called <MyLibrary>Tests and connect gtest library.
This way guarantees that your library will be under testing and when you'll run your tests, you could attach to this process.
To attach your codebase to the application, you have to use menu option Debug → Attach to Process...:
When you press it, you'll be able to find your application which is using your library currently.
And, as I understand on my last work place, the best way to debug your library is make your small GUI application with some buttons for testing. It's pretty enough to make a simple Python app to check it.
From Specify symbol (.pdb) and source files in the Visual Studio debugger (C#, C++, Visual Basic, F#), the quickest way to fix this is via the Modules Window in the Debugger:
Put a breakpoint after your call.LoadLibrary
Go to Debug->Windows->Modules in the menu bar to bring up the Modules window.
Search for your dll file in the list. In the Symbol Status column it should read "Cannot find or open the PDB file".
Right click the dll and choose Load Symbols from the context menu.
Point it to the correct pdb file.
The Symbol Status should now change to "Symbols Loaded".
You should now be able to step into functions from the dll and add breakpoints.
Related
How can I debug a dll using visual studio?
I have the DLL source, pdb, etc.
I tried these options:
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
void DebugBreak();
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
{
//...
}
break;
case DLL_PROCESS_DETACH:
{
//...
}
break;
}
);
return TRUE;
}
It launches the exe but doesn't inject the DLL, by default this exe didn't load the DLL, im manually injecting it.
Is possible to visual studio attach the DLL? and be able to put breakpoints on it, view call stack on a crash, etc?
The quickest way to fix this is via the Modules Window in the Debugger:
Put a breakpoint after your LoadLibrary call.
Go to Debug->Windows->Modules in the menu bar to bring up the Modules window.
Search for your dll file in the list. In the Symbol Status column
it should read "Cannot find or open the PDB file".
Right click the dll and choose Load Symbols from the context menu.
Point it to the correct pdb file.
The Symbol Status should now change to "Symbols Loaded".
You should now be able to step into functions from the dll and put breakpoints.
I have a Visual Studio 2013 C++ DLL project.
The build DLL works fine, except one point: There is a lack of interactive form which should open when DLL starts & it should be responsive to/from the DLL
I had referred to this link
I tried:
Right click on Project-> Select Add->Resource->Dialog
After that, a blank Dialog box appeared in the Visual Studio tab and it was listed in the Resources folder
I thought simply compiling the project would make the empty Dialog box display while running the DLL.
But even the empty Dialog box is not displayed when I run the DLL
Am I missing something here?
Also, would C++ be sufficient to add functionality to the form/Dialog? Or, any other language like C#?
(So that I may add event handling kind of functionality to that)
I suggest that you could use MFC to add functionality to the form/Dialog.
Here are the steps:
Create a MFC DLL named 'CTestDll', and select Regular DLL using shared MFC DLL
Then select Add->Resource->Dialog
Add code in CTestDll.cpp
#include "CTestDlg.h"
extern "C" __declspec(dllexport) void Show()
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
CTestDlg test;
test.DoModal();
}
Create a MFC App for testing. You could call it through the button click event.
void CMFCApplication3Dlg::OnBnClickedButton1()
{
// TODO: Add your control notification handler code here
typedef void (WINAPI *TESTDLL)();
HINSTANCE hInstance = LoadLibrary(_T("CTestDll.dll")); //
if (hInstance != NULL)
{
TESTDLL TestShow = (TESTDLL)GetProcAddress(hInstance, "Show");
if (TestShow != NULL)
{
TestShow();
}
FreeLibrary(hInstance);
}
}
I added the lua package to my c++ project, but anytime lua is included in my project no functions are called when my DLL gets attached, but when I dont include lua the messagebox appears on attachment. I'm certain it isn't the injection program since I tested my DLL w/ multiple programs and it's now driving me crazy. Does anyone have any solutions or steps in the right path? I would really appreciate it!
Package Used: https://bitbucket.org/sgrottel_nuget/lua/overview
EDIT: Including lua headers will remove functionality from my dll. Removing the lua headers (commenting out "#include "lua.hpp") will let the messagebox pop up. Am I using the lua package wrong or is there a small step I missed?
#include "FVM.h" // includes lua headers etc. (when removed function works on attachment)
// Entry point
BOOL APIENTRY DllMain(HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
MessageBoxA(NULL, "attached", "Function", MB_OK);
case DLL_THREAD_ATTACH:
MessageBoxA(NULL, "attached", "Function", MB_OK);
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
I can't reproduce this issue. Please follow my steps to see if it can reproduce this issue.
Create a main application using Windows Desktop Application template.
Create a DLL application using Dynamic-Link Library(DLL) template.
Install LUA nuget package to the DLL application.
Add the header file to the dllmain.cpp and add MessageBoxA same with your code.
Load DLL in the main application:
HMODULE myDll = LoadLibraryA("D:\\TestDllLoad\\Debug\\Dll1.dll");
The result is the message box display "attached" every time I launch the main application.
I'm trying to make this console program and it has to resize the console itself to put the text I want in it, so I used this method to resize it:
#include <windows.h>
using namespace std;
int main ()
{
HWND console = GetConsoleWindow();
RECT r;
GetWindowRect(console, &r); //stores the console's current dimensions
MoveWindow(console, r.left, r.top, 775, 575, TRUE); // 775 width, 575 height
}
It works perfectly with the rest of my code. The only problem is that when I send my program to a friend it says "MSVCP140.dll" is missing in his PC.
So to fix this what I always do is change in Visual Studio's Project settings from "Use Standard Windows Libraries" to "Use Static MFC Library" and that way it won't ask for "MSVCP140.dll". The only problem here is that when I set it to Use Static MFC Library it throws this error:
Unresolved external symbol _imp_GetWindowRect
Unresolved external symbol _imp_MoveWindow
If I remove the Console resize command from above, it will work no problem. So the problem is basically that if I use the Console Resize I have to use Standard Library and if I don't I can use MFC Library. but I need to use the Console resize with the MFC so it doesn't ask for a .dll to open on other's computer.
I'm going crazy over here. Any ideas/thoughts?
I believe you're changing the wrong setting. If you're not using MFC, leave the "Use of MFC" option at "Use Standard Windows Libraries".
Instead, look under "C/C++ / Code Generation" and change the "Runtime Library" option from "Multi-threaded DLL" to "Multi-threaded"
Similarly, in Debug mode, you'd switch from "Multi-threaded Debug DLL" to just "Multi-threaded Debug"
or
You could have your friend download & install the Visual C++ Redistributable for Visual Studio 2015
I have a C++ dll which implements several COM interfaces, that I'm trying to migrate to managed C++. I set the /clr compiler flag and changed the Runtime Library property from /MT to /MD to avoid the conflict between these two flags, but that's all I've changed. When it attempts to register the dll during the build process, I get the following error:
R6033 - Attempt to use MSIL code from this assembly during native code initialization
This indicates a bug in your application. It is most likely the result of calling an MSIL-compiled (/clr) function from a native constructor or from DllMain.
I read about Loader Lock and can't figure it out - I have not added a single call to any managed code. Here's the entire body of the DllMain procedure:
[Edit - per comment below, I added #pragma unmanaged to the top of the cpp file with no improvement. The Module init is all code contained in the ATL libraries from what I can tell.]
extern "C"
BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
lpReserved;
if (dwReason == DLL_PROCESS_ATTACH)
{
_Module.Init(ObjectMap, hInstance, &MYGUID);
DisableThreadLibraryCalls(hInstance);
}
else if (dwReason == DLL_PROCESS_DETACH)
_Module.Term();
return TRUE; // ok
}
You need to add the /clr compiler flag only to the files that use managed code and not for the whole project.
This is what the Visual Studio "Wizard" does, here is how I've tested:
Create a Visual C++ ATL Project
Added a ATL Simple Object, in order to have a COM interface (Project->Add Class)
Added a CLR Component Class. The Wizard prompted me with "You are adding a CLR component to a native project. Your project will be converted to have Common Language Runtime support."
Compile project, compiles fine and registers fine.
Checked the project settings -> "No Common Language Runtime support"
Checked the clrcomponennt.cpp settings -> "Common Language Runtime Support (/clr)"
Opened the dll in OleView -> COM interface was present
Opened the dll in Red Gate's .NET Reflector -> clrcomponent was present
Using /clr flag has made your methods managed (ie. they are being compiled down to MSIL), but you're calling them for DllMain which -isn't- managed. Unfortunately, that's about as far as my limited knowledge can take it.