unable to step into a function of a different project (both in C++) under the same solution with VS2019

Question

unable to step into a function of a different project (both in C++) under the same solution with VS2019

Cindy Wang 1

Hi experts,

I am new with VS environment, and I am being asked to take over a product developed in VS.

There are multiple projects in C++ for the solution I am working with VS2019. The starting project TestConsole has dependencies on another project (saspiwpr) under the same solution. The problem I am having is unable to step into function in saspiwpr from TestConsole. I did googling and did the following:

Make sure that the projects are being built for DEBUG x64
Added the path for saspiwpr explicitly from solution’s property->common properties->debug source files
Added the reference of saspiwpr under TestConsole, and set its property COPY LOCAL to be TRUE

Still not able to step into the source code, but get a prompt to step into assembly code instead.

Is there anything else I should do in order to solve this problem?

Thanks a lot for your help!

-Cindy

David Lowndes 4,726 Reputation points

2021-12-07T09:44:17.71+00:00

Are both projects native C++ ones (not managed code)?
If when debugging you examine the modules pane (Debug, Windows, Modules) what does it show for the Symbol File for your DLL?
Tianyu Sun-MSFT 34,441 Reputation points Microsoft External Staff

2021-12-07T09:56:49.493+00:00

Hi @Cindy Wang , while debugging, you can click Debug > Windows > Modules, and make sure that the specific modules/symbols are loaded correctly. Besides, is it possible for you to share some minimal example/key codes for reproducing this issue?
RLWA32 49,551 Reputation points

2021-12-07T10:49:43.333+00:00

Another general step to consider is to create a new solution with a DLL project and an Application project that consumes the DLL.

Lets assume that after you build the solution for x64 Debug the debugger is able to step into the DLL source code. You could then compare the project files (.vcxproj) in the test solution to the problematic projects to look for any unexpected differences in project properties.
Cindy Wang 1 Reputation point

2021-12-07T16:02:40.437+00:00

Thanks for your response David!

I looked the modules pane while debugging TestConsole, and saspiwpr.dll is not being listed there. So the question is how would I add that?

Thanks again for your help!

-Cindy
Cindy Wang 1 Reputation point

2021-12-07T16:05:37.017+00:00

Thanks for your response Tianyu!

I looked the modules pane while debugging TestConsole, and saspiwpr.dll is not being listed there. So the question is how would I add that?

The example is TestConsole calls a function in saspiwpr, where both TestConsole and saspiwpr are in C++ and under the same location.

Thanks again for your help!

-Cindy
RLWA32 49,551 Reputation points

2021-12-07T17:26:17.377+00:00

If the modules pane does not show saspiwpr.dll then how do you know that the prompt to step into assembly code is for that dll?
David Lowndes 4,726 Reputation points

2021-12-07T17:54:31.67+00:00

If it's lot listed there, it hasn't been loaded, so it's no wonder you can't step into it.
I think there's some detail of your situation that we're missing because this scenario shouldn't be a problem.
RLWA32 49,551 Reputation points

2021-12-07T18:44:43.013+00:00

And if TestConsole uses load time linking for the dll then an inability to load it would result in the application not starting. So I agree, there's definitely a disconnect somewhere.
Cindy Wang 1 Reputation point

2021-12-07T18:50:24.333+00:00

You are right. It is no longer stepping into assembly code since I made some changes. I am not sure what changes I made caused that though.

Is there a way to add the module? Everything runs to completion as expected,, just the debugging is not working still.

Thanks!
-Cindy
Cindy Wang 1 Reputation point

2021-12-07T19:25:02.243+00:00

I gave the wrong information.

So the saspiwpi.dll was not listed when the program was firsted started, but as I continue to run the program, it gets listed under the modules:

saspiwpr.dll saspiwpr.dll C:\pp_dbipiaf_v940m8\PISystem\x64\Debug\saspiwpr.dll N/A Yes Symbols loaded. C:\pp_dbipiaf_v940m8\PISystem\x64\Debug\saspiwpr.pdb 7 9.40 12/6/2021 9:41 PM 00007FFFA3530000-00007FFFA3564000 [24724] TestConsole.exe

Sorry about the confusion. As you know, I am very new to VS environment and on my learning curve still.

Thanks!
-Cindy
David Lowndes 4,726 Reputation points

2021-12-07T21:23:31.16+00:00

OK, so it sounds like it's being dynamically loaded - and VS appears to have the symbols for it.
When it's in that loaded state, can you open the source for that project and put a breakpoint in that will be hit?
Cindy Wang 1 Reputation point

2021-12-08T18:30:15.05+00:00

yeah, you are right. It is loaded by LoadLibrary() call. I tried to set a break point after it is being loaded, but the break point indicates that "The breakpoint will not currently be hit. No executable code of the debugger's target code type is associated with this line".

Thanks!
-Cindy
David Lowndes 4,726 Reputation points

2021-12-08T18:42:05.077+00:00

I'm guessing, but it seems to me that the DLL that's loaded (and you have symbols for) isn't perhaps the same version as the source code.
It is a debug build (without optimization) with full symbol information that you're building for that DLL, isn't it?
Have you tried placing breakpoints at lots of other lines of code in that DLL (including lines that don't appear to have code) to see if any of them stick?
RLWA32 49,551 Reputation points

2021-12-08T19:16:52.247+00:00

Presumably you have the source code and the dll project that you could use to rebuild the dll. That would ensure that the debugging information and the new symbol file would match the source code used to rebuild the dll.
Cindy Wang 1 Reputation point

2021-12-08T21:00:03.3+00:00

I tried to clean the solution and rebuild the solution, and also tried multiple break points after the dll is being loaded, but still can't make it to work.

I also checked saspiwpr.dll (being loaded by TestConsole) was built for debug, and both saspiwpr.dll and saspiwpr.pdb are under the debug path under which TestConsole.exe is found:

C:\playpen\piSolution\x64\Debug

Thanks!
-Cindy
RLWA32 49,551 Reputation points

2021-12-08T21:49:41+00:00

C:\pp_dbipiaf_v940m8\PISystem\x64\Debug\saspiwpr.dll

That was the file system location you previously posted for the dll.

Now you say you are using the saspiwpr.dll that is located here -

C:\playpen\piSolution\x64\Debug

So again, it is not clear what version of the dll you may have rebuilt and what version is actually loading while debugging.
Cindy Wang 1 Reputation point

2021-12-08T22:19:22.103+00:00

Sorry for the confusion. It is the same path. I modified the name to make it look more simple.

Thanks!
-Cindy
RLWA32 49,551 Reputation points

2021-12-08T22:48:38.933+00:00

Check the the call to the LoadLibrary function in the TestConsole source code. Does it include a path to saspiwpr.dll?
Cindy Wang 1 Reputation point

2021-12-08T23:02:37.817+00:00

It does not include the path:

lib = LoadLibrary (L"saspiwpr.dll");
RLWA32 49,551 Reputation points

2021-12-08T23:49:27.617+00:00

Set a break point in TestConsole.exe on the statement immediately following the call to LoadLibrary. At that point the dll should be loaded and you should see it in the modules pane. If the modules pane indicates that the symbol file has not been loaded right click on the dll line and try to manually load the symbol file. You should also be able to verify that the file system location of the loaded dll is correct.
Cindy Wang 1 Reputation point

2021-12-09T01:56:51.817+00:00

I set a break point right after the call to LoadLibrary as you suggested. And the modules pane indicates that the symbol file has been loaded:
saspiwpr.dll saspiwpr.dll C:\pp_dbipiaf_v940m8\PISystem\x64\Debug\saspiwpr.dll N/A Yes Symbols loaded. C:\pp_dbipiaf_v940m8\PISystem\x64\Debug\saspiwpr.pdb 7 9.40 12/8/2021 2:44 PM 00007FFFA2A30000-00007FFFA2A64000 [10372] TestConsole.exe

And the path seems correct too.

Thanks for your suggestions!
-Cindy
RLWA32 49,551 Reputation points

2021-12-09T02:13:15.877+00:00

Okay, since both the dll and its symbol file are loaded you should be able to set a breakpoint in the dlls source code. Have you tried to do this?

If you are still unable to set a break point in the dlls source code go to the project properties of the dll and tell us what is set for the format of the debugging information in the compiler options.
Cindy Wang 1 Reputation point

2021-12-09T02:34:32.583+00:00

I tried to set break point, but it indicated that:
"The breakpoint will not currently be hit. No executable code of the debugger's target code type is associated with this line"

Where can I find the compiler options?

Thanks!
-Cindy
RLWA32 49,551 Reputation points

2021-12-09T02:40:45.813+00:00

Instructions for finding the project property setting are here

z7-zi-zi-debug-information-format
Cindy Wang 1 Reputation point

2021-12-09T03:08:15.78+00:00

The debug information format is: Program Database (/Zi)
RLWA32 49,551 Reputation points

2021-12-09T03:12:42.42+00:00

That was the format setting for all platform / configurations?
Cindy Wang 1 Reputation point

2021-12-09T03:22:57.527+00:00

yes, that is for all configurations and all platforms.
RLWA32 49,551 Reputation points

2021-12-09T03:26:20.897+00:00

Also please verify that even though you are building the dll in the debug configuration that compiler optimization is actually disabled. Check the dll project property here
od-disable-debug
Cindy Wang 1 Reputation point

2021-12-09T03:39:43.173+00:00

The optimization shows: <different options> .
RLWA32 49,551 Reputation points

2021-12-09T03:42:55.713+00:00

What does it show for optimization specifically for x64 debug?
Cindy Wang 1 Reputation point

2021-12-09T03:54:20.597+00:00

It shows Disabled for Debug/x64.
RLWA32 49,551 Reputation points

2021-12-09T04:00:35.517+00:00

Well, at this point I don't know what else to ask you. According to all your responses I can think of no reason why you are unable to set a break point in the dll source code.

Can you share with us a sample that reproduces the issue?

1 answer

Your answer

David Lowndes 4,726 Reputation points

2021-12-07T09:44:17.71+00:00

Are both projects native C++ ones (not managed code)?
If when debugging you examine the modules pane (Debug, Windows, Modules) what does it show for the Symbol File for your DLL?
Tianyu Sun-MSFT 34,441 Reputation points Microsoft External Staff

2021-12-07T09:56:49.493+00:00

Hi @Cindy Wang , while debugging, you can click Debug > Windows > Modules, and make sure that the specific modules/symbols are loaded correctly. Besides, is it possible for you to share some minimal example/key codes for reproducing this issue?
RLWA32 49,551 Reputation points

2021-12-07T10:49:43.333+00:00

Another general step to consider is to create a new solution with a DLL project and an Application project that consumes the DLL.

Lets assume that after you build the solution for x64 Debug the debugger is able to step into the DLL source code. You could then compare the project files (.vcxproj) in the test solution to the problematic projects to look for any unexpected differences in project properties.
Cindy Wang 1 Reputation point

2021-12-07T16:02:40.437+00:00

Thanks for your response David!

I looked the modules pane while debugging TestConsole, and saspiwpr.dll is not being listed there. So the question is how would I add that?

Thanks again for your help!

-Cindy
Cindy Wang 1 Reputation point

2021-12-07T16:05:37.017+00:00

Thanks for your response Tianyu!

I looked the modules pane while debugging TestConsole, and saspiwpr.dll is not being listed there. So the question is how would I add that?

The example is TestConsole calls a function in saspiwpr, where both TestConsole and saspiwpr are in C++ and under the same location.

Thanks again for your help!

-Cindy
RLWA32 49,551 Reputation points

2021-12-07T17:26:17.377+00:00

If the modules pane does not show saspiwpr.dll then how do you know that the prompt to step into assembly code is for that dll?
David Lowndes 4,726 Reputation points

2021-12-07T17:54:31.67+00:00

If it's lot listed there, it hasn't been loaded, so it's no wonder you can't step into it.
I think there's some detail of your situation that we're missing because this scenario shouldn't be a problem.
RLWA32 49,551 Reputation points

2021-12-07T18:44:43.013+00:00

And if TestConsole uses load time linking for the dll then an inability to load it would result in the application not starting. So I agree, there's definitely a disconnect somewhere.
Cindy Wang 1 Reputation point

2021-12-07T18:50:24.333+00:00

You are right. It is no longer stepping into assembly code since I made some changes. I am not sure what changes I made caused that though.

Is there a way to add the module? Everything runs to completion as expected,, just the debugging is not working still.

Thanks!
-Cindy
Cindy Wang 1 Reputation point

2021-12-07T19:25:02.243+00:00

I gave the wrong information.

So the saspiwpi.dll was not listed when the program was firsted started, but as I continue to run the program, it gets listed under the modules:

saspiwpr.dll saspiwpr.dll C:\pp_dbipiaf_v940m8\PISystem\x64\Debug\saspiwpr.dll N/A Yes Symbols loaded. C:\pp_dbipiaf_v940m8\PISystem\x64\Debug\saspiwpr.pdb 7 9.40 12/6/2021 9:41 PM 00007FFFA3530000-00007FFFA3564000 [24724] TestConsole.exe

Sorry about the confusion. As you know, I am very new to VS environment and on my learning curve still.

Thanks!
-Cindy
David Lowndes 4,726 Reputation points

2021-12-07T21:23:31.16+00:00

OK, so it sounds like it's being dynamically loaded - and VS appears to have the symbols for it.
When it's in that loaded state, can you open the source for that project and put a breakpoint in that will be hit?
Cindy Wang 1 Reputation point

2021-12-08T18:30:15.05+00:00

yeah, you are right. It is loaded by LoadLibrary() call. I tried to set a break point after it is being loaded, but the break point indicates that "The breakpoint will not currently be hit. No executable code of the debugger's target code type is associated with this line".

Thanks!
-Cindy
David Lowndes 4,726 Reputation points

2021-12-08T18:42:05.077+00:00

I'm guessing, but it seems to me that the DLL that's loaded (and you have symbols for) isn't perhaps the same version as the source code.
It is a debug build (without optimization) with full symbol information that you're building for that DLL, isn't it?
Have you tried placing breakpoints at lots of other lines of code in that DLL (including lines that don't appear to have code) to see if any of them stick?
RLWA32 49,551 Reputation points

2021-12-08T19:16:52.247+00:00

Presumably you have the source code and the dll project that you could use to rebuild the dll. That would ensure that the debugging information and the new symbol file would match the source code used to rebuild the dll.
Cindy Wang 1 Reputation point

2021-12-08T21:00:03.3+00:00

I tried to clean the solution and rebuild the solution, and also tried multiple break points after the dll is being loaded, but still can't make it to work.

I also checked saspiwpr.dll (being loaded by TestConsole) was built for debug, and both saspiwpr.dll and saspiwpr.pdb are under the debug path under which TestConsole.exe is found:

C:\playpen\piSolution\x64\Debug

Thanks!
-Cindy
RLWA32 49,551 Reputation points

2021-12-08T21:49:41+00:00

C:\pp_dbipiaf_v940m8\PISystem\x64\Debug\saspiwpr.dll

That was the file system location you previously posted for the dll.

Now you say you are using the saspiwpr.dll that is located here -

C:\playpen\piSolution\x64\Debug

So again, it is not clear what version of the dll you may have rebuilt and what version is actually loading while debugging.
Cindy Wang 1 Reputation point

2021-12-08T22:19:22.103+00:00

Sorry for the confusion. It is the same path. I modified the name to make it look more simple.

Thanks!
-Cindy
RLWA32 49,551 Reputation points

2021-12-08T22:48:38.933+00:00

Check the the call to the LoadLibrary function in the TestConsole source code. Does it include a path to saspiwpr.dll?
Cindy Wang 1 Reputation point

2021-12-08T23:02:37.817+00:00

It does not include the path:

lib = LoadLibrary (L"saspiwpr.dll");
RLWA32 49,551 Reputation points

2021-12-08T23:49:27.617+00:00

Set a break point in TestConsole.exe on the statement immediately following the call to LoadLibrary. At that point the dll should be loaded and you should see it in the modules pane. If the modules pane indicates that the symbol file has not been loaded right click on the dll line and try to manually load the symbol file. You should also be able to verify that the file system location of the loaded dll is correct.
Cindy Wang 1 Reputation point

2021-12-09T01:56:51.817+00:00

I set a break point right after the call to LoadLibrary as you suggested. And the modules pane indicates that the symbol file has been loaded:
saspiwpr.dll saspiwpr.dll C:\pp_dbipiaf_v940m8\PISystem\x64\Debug\saspiwpr.dll N/A Yes Symbols loaded. C:\pp_dbipiaf_v940m8\PISystem\x64\Debug\saspiwpr.pdb 7 9.40 12/8/2021 2:44 PM 00007FFFA2A30000-00007FFFA2A64000 [10372] TestConsole.exe

And the path seems correct too.

Thanks for your suggestions!
-Cindy
RLWA32 49,551 Reputation points

2021-12-09T02:13:15.877+00:00

Okay, since both the dll and its symbol file are loaded you should be able to set a breakpoint in the dlls source code. Have you tried to do this?

If you are still unable to set a break point in the dlls source code go to the project properties of the dll and tell us what is set for the format of the debugging information in the compiler options.
Cindy Wang 1 Reputation point

2021-12-09T02:34:32.583+00:00

I tried to set break point, but it indicated that:
"The breakpoint will not currently be hit. No executable code of the debugger's target code type is associated with this line"

Where can I find the compiler options?

Thanks!
-Cindy
RLWA32 49,551 Reputation points

2021-12-09T02:40:45.813+00:00

Instructions for finding the project property setting are here

z7-zi-zi-debug-information-format
Cindy Wang 1 Reputation point

2021-12-09T03:08:15.78+00:00

The debug information format is: Program Database (/Zi)
RLWA32 49,551 Reputation points

2021-12-09T03:12:42.42+00:00

That was the format setting for all platform / configurations?
Cindy Wang 1 Reputation point

2021-12-09T03:22:57.527+00:00

yes, that is for all configurations and all platforms.
RLWA32 49,551 Reputation points

2021-12-09T03:26:20.897+00:00

Also please verify that even though you are building the dll in the debug configuration that compiler optimization is actually disabled. Check the dll project property here
od-disable-debug
Cindy Wang 1 Reputation point

2021-12-09T03:39:43.173+00:00

The optimization shows: <different options> .
RLWA32 49,551 Reputation points

2021-12-09T03:42:55.713+00:00

What does it show for optimization specifically for x64 debug?
Cindy Wang 1 Reputation point

2021-12-09T03:54:20.597+00:00

It shows Disabled for Debug/x64.
RLWA32 49,551 Reputation points

2021-12-09T04:00:35.517+00:00

Well, at this point I don't know what else to ask you. According to all your responses I can think of no reason why you are unable to set a break point in the dll source code.

Can you share with us a sample that reproduces the issue?

Answer 1

RLWA32 49,551

Make sure that the saspiwpr project is generating a PDB. Check the linker properties linker-property-pages

Cindy Wang 1 Reputation point

2021-12-06T23:11:28.797+00:00

Thanks for your response RLWA32-6255!

I just checked that the property for saspiwpr project-->linker-->debugging:

Generate Debug Information is already set to be: Generate Debug Information (/DEBUG)

-Cindy
RLWA32 49,551 Reputation points

2021-12-06T23:16:41.617+00:00

Properties can be set individually for different combinations of platform/configuration. So verify that the debug properties that you checked were in fact for the x64 platform.
RLWA32 49,551 Reputation points

2021-12-06T23:22:33.333+00:00

Also, check the debugger options for symbol files to ensure that the debugger is configured to load them for all modules. These settings are not project properties but are visual studio IDE options.
Cindy Wang 1 Reputation point

2021-12-06T23:25:03.797+00:00

I checked, and it is for all Platforms and configuration of DEBUG.
Cindy Wang 1 Reputation point

2021-12-07T02:40:10.113+00:00

I took a screen shot of the tools-->options-->Debugging which I am attaching. It looks like it loads for all modules.

Thanks!
-Cindy
RLWA32 49,551 Reputation points

2021-12-07T03:51:19.123+00:00

Have you looked in the output directories for your projects to verify that they do contain the symbol files for your projects?

Another project property to check is the debug information format and compiler options.

Share via

unable to step into a function of a different project (both in C++) under the same solution with VS2019

1 answer

Your answer