Can't get Visual Studio 2019 to keep a C++ console app running in the background

Question

Can't get Visual Studio 2019 to keep a C++ console app running in the background

Bishop Minter 41

I'm building a text-based MUD game. I can run the game from a normal cmd prompt but I want to run it through the VS 2019 debugger so I can test changes made to the code in real time. The problem is VS 2019 is parsing the exe file differently than the cmd prompt and closes the process after the debugger runs. When I do a diffcheck on the outputs from VS 2019 vs cmd prompt they are almost identical except for 2 parts.

cmd prompt output not shown in the VS output

<code>
:: ipv6 support not enabled, ignoring: 'telnet://[::]:+0'
:: socket 492 listening as telnet on 0.0.0.0:4000.
:: ipv6 support not enabled, ignoring: 'http://[::]:+1'
:: socket 500 listening as http on 0.0.0.0:4001.
:: Starting hostname/ident resolver process...
:: [*****] BUG: C:\Dawn Of Time\DAWNTEST\dawntest\resolver.exe not found!
:: *************************************************************************
Resolver.exe is used to convert IP addresses into domain names (seen using
the sockets command). Currently the gamesetting flag
'perform_local_dns_lookups' is turned off, so there is no IP to domain name
conversion. You can turn this on within gameedit so the translation of IP
address to domain names will be performed by the mud itself. The only down
side of turning on this option is that when the mud looks up the domain name
of an ip address, it waits for the answer. If the IP doesn't have a domain
name, the mud will stall for all players until the lookup it times out after
about 30 seconds.

:: Querying resolvers version.
</code>

end of cmd prompt output

<code>
:: We are running on DESKTOP-1UI98DM.
:: The current working directory is C:\Dawn Of Time\DAWNTEST.
:: The hostname/ident resolver is not currently running.
:: PlatformID: WindowsNT v6.2.9200 []
:: Free stringspace =607349.
:: Dawn v1.69r based mud on DESKTOP-1UI98DM is ready to rock.
:: Logging to logs\game\4000-211002-04.log
:: Mud is running in the foreground with a process id of 24592
:: Pressing ctrl+c will terminate the mud process (unless you have hotrebooted)
:: installing atexit and signal handlers
:: The mud is waiting for connections on the following addresses:
:: s492> telnet port: 4000, ipv4 address: 0.0.0.0
:: s484> http port: 4001, ipv4 address: 0.0.0.0
:: Updating Areas
Sat Oct 2 10:19:09 :: Tick
</code>

end of VS 2019 console output

<code>
:: We are running on t\Debug\dawntest.exe.
:: The current working directory is C:\Dawn Of Time\DAWNTEST.
:: The hostname/ident resolver is not currently running.
:: PlatformID: WindowsNT v6.2.9200 []
:: Boot test completed OK!!!

C:\Dawn Of Time\DAWNTEST\dawntest\Debug\dawntest.exe (process 7116) exited with code 0.
To automatically close the console when debugging stops, enable Tools->Options->Debugging->Automatically close the console when debugging stops.
Press any key to close this window . . .
</code>

As you can see, when I execute the exe from the cmd prompt it loads and then the process continues to run. In other words, the game continues to run until I close it. But when I execute the code in the debugger I get "Boot test complete OK!!!" and the process exits with code 0. I need a way to run the process through the VS console and remain open and running instead of closing out.

Can you help me with this?

Accepted answer

1 additional answer

Your answer

Answer 1

RLWA32 49,636

But now I have 2 problems. One, I can't figure out what's changing the variable from false to true. I set a watch and the variable is being changed by a strcpy function. This doesn't make any sense to me because that's a standard C library function that copies one string to a different destination. When we get to this function
strcpy(EXE_FILE, exename);
EXE_FILE is empty and exename is C:\Dawn Of Time\DAWNTEST\dawntest\Debug\dawntest.exe. After the function runs EXE_FILE is C:\Dawn Of Time\DAWNTEST\dawnt (incomplete because the EXE_FILE variable only has 30 chars) and exename is the same as before. And fBootTestOnly magically changes from false to true.

Sounds like you have a buffer overrun bug. Use the strcpy_s function instead of strcpy. You could also increase the size of the EXE_FILE buffer.

Bishop Minter 41 Reputation points

2021-10-04T18:24:20.12+00:00

II changed the buffer from 30 to 55 and that worked. Thanks for your help.
RLWA32 49,636 Reputation points

2021-10-04T18:44:51.267+00:00

You're welcome.

Answer 2

RLWA32 49,636

It appears that your are using two processes. The post above mentions process id 24592 and process id 7116. As provided by Microsoft, the Visual Studio Debugger does not debug child processes that are started by a parent that is being debugged. However, Windbg.exe does provide that capability. Additionally, there is an extension for Visual Studio that enables child process debugging. I have not used it. See Microsoft Child Process Debugging Power Tool. Also, you can manually attach the Visual Studio debugger to a process if you know the process Id.

Bishop Minter 41 Reputation points

2021-10-02T16:03:50.213+00:00

They are two separate processes true but they are completely separate processes that I want to produce the same result. Maybe some clarification will help. When I use the cmd prompt to start the game it runs in the cmd prompt in the background. I then use a front end client (MUSHClient) to telnet to the game (127.0.0.1 4000). Then I play the game via the client. What I want to do is start the MUD in debug mode in VS and have the MUD run in the VS console in the background then use my client to attach to process just like before (telnet 127.0.0.1 4000). This way when I enter a command in the client I can step the the process of that command in the debugger (after setting a break point at the appropriate place in the code). So I'm not trying to run both processes at the same time. I just want to play the game via VS like I am able to do using the cmd prompt. I posted the code snippets to provide the differences in the output in each of the methods used in the hopes that the answer to why VS parses the boot up process differently than the cmd line could be determined.

Does that help any?
RLWA32 49,636 Reputation points

2021-10-02T16:14:00.873+00:00

Have you stepped through the code of the process running in the visual studio debugger to determine why it terminates prematurely?
Bishop Minter 41 Reputation points

2021-10-02T18:14:09.367+00:00

Ok I followed the code and found that a variable fBootTestOnly was being set to true and that was causing the process to terminate at that point. If I go through the debugger and change the variable back to false before that function runs I can make the process finish out and the code works as expected with the mud running in the background.

But now I have 2 problems. One, I can't figure out what's changing the variable from false to true. I set a watch and the variable is being changed by a strcpy function. This doesn't make any sense to me because that's a standard C library function that copies one string to a different destination. When we get to this function

strcpy(EXE_FILE, exename);

EXE_FILE is empty and exename is C:\Dawn Of Time\DAWNTEST\dawntest\Debug\dawntest.exe. After the function runs EXE_FILE is C:\Dawn Of Time\DAWNTEST\dawnt (incomplete because the EXE_FILE variable only has 30 chars) and exename is the same as before. And fBootTestOnly magically changes from false to true.

Two, even though the process is running it does not appear to have a port to connect to. When run from the cmd prompt I get this:

:: The mud is waiting for connections on the following addresses:
:: s492> telnet port: 4000, ipv4 address: 0.0.0.0
:: s484> http port: 4001, ipv4 address: 0.0.0.0

and I can telnet via my client to 127.0.0.1 port 4000. But VS just gives me this:

:: The mud is waiting for connections on the following addresses:

and begins with the first tick in the game.

Share via

Can't get Visual Studio 2019 to keep a C++ console app running in the background

1 additional answer

Your answer