You can find the connection string with an API Monitor tool or Debugger. However first you will need to know are you looking at .NET based executable (i.e. has it loaded clr.dll or mscorlib.dll) and how does it access the database.
To work this out you can use a tool like Process Monitor and filter on Process Name is Include and Operation is Load Image ...
I found the solution when reading these two articles:
https://pentest-tools.com/blog/bluekeep-exploit-metasploit/ (Extracting the NPP Address)
https://medium.com/@alexandrevvo/testing-bluekeep-cve-2019-0708-metasploit-module-on-windows-7-ef3f28217b7b (Finding the NPP)
Your program may be using certain tricks like using the exception handler vector in order to misguide the execution of your program when launched by a debugger.
Be sure to use a non invasive debugger which also does not register itself as a debugger. I think that natively x64dbg requires a plugin for this job, but usually I resort to ollydbg.
When you ...
You can debug .NET code with an assembly debugger of your choice, it's fun, and sometimes, the only way to spot rare and nasty issues. However you'll end up on having a lot of noise since you'll debug the virtual machine of the .NET runtime, losing what the original .NET code was intended to do.
To debug .NET code and assembly at the very same time you can ...
One way is to patch the bytes on IDA, and create a diff file. Use it to change the binary.
Another way that is useful in averting some verification techniques is to generate an executable on runtime from the current memory dump(after you applied patches).
This way the program will start from a certain state that you can set.
Ollydbg had this plugin. I am ...
It might be useful to check the command line that was used to start the program.
Open the Details tab of Task Manager and right click on any column (Name/PID/status). Then choose "Select columns" and in the new window scroll down and check the "Command line" box (below the I/O ones).