Difficulty with Visual Studio
-
I have been compiling and running C and C++ programs for very many years: first DJGPP for DOS; then Borland C; then Visual C. Until today, Visual C++ 2017 has given me reliable service. My programs have been settled in their final forms for use and I have not needed to recompile them for over a year. Today, on one of my projects (a graphics handling program), for the first time for over a year, I ventured to try to put a new facility into it. I went into my copy of Microsoft Visual C++ 2017, which at the time was set to Debug mode rather than to Release mode. I recompiled the altered program. It compiled and said that there were no programming errors. But attempt to run the compiled program (which is on my computer in C:\2d\ppp\Debug\ppp.exe ) resulted in a hesitation followed by an exit without displaying some text that it should have made. Meanwhile, the Release version, which is in C:\2d\ppp\Release\ppp.exe , which I had wisely and thankfully left alone and I did not recompile it, still runs as it should and as it has run faithfully for many years. Attempt to run the debugging option (as from the word "Debug" in the top long menu) crashes out with an exception on the instruction "test dword ptr [eax],eax ; probe page.". I tried to run Visual 2019, but its menu display is so different from what I know in Visual 2017 that I could not make head or tail of it. This means that my C++ programs are now stuck as they are and I cannot change them any more. Please how can I get my Visual C++ 2017 to run as it has run reliably for very many years? It was quite enough and adequate for me. What is happening?
-
I have been compiling and running C and C++ programs for very many years: first DJGPP for DOS; then Borland C; then Visual C. Until today, Visual C++ 2017 has given me reliable service. My programs have been settled in their final forms for use and I have not needed to recompile them for over a year. Today, on one of my projects (a graphics handling program), for the first time for over a year, I ventured to try to put a new facility into it. I went into my copy of Microsoft Visual C++ 2017, which at the time was set to Debug mode rather than to Release mode. I recompiled the altered program. It compiled and said that there were no programming errors. But attempt to run the compiled program (which is on my computer in C:\2d\ppp\Debug\ppp.exe ) resulted in a hesitation followed by an exit without displaying some text that it should have made. Meanwhile, the Release version, which is in C:\2d\ppp\Release\ppp.exe , which I had wisely and thankfully left alone and I did not recompile it, still runs as it should and as it has run faithfully for many years. Attempt to run the debugging option (as from the word "Debug" in the top long menu) crashes out with an exception on the instruction "test dword ptr [eax],eax ; probe page.". I tried to run Visual 2019, but its menu display is so different from what I know in Visual 2017 that I could not make head or tail of it. This means that my C++ programs are now stuck as they are and I cannot change them any more. Please how can I get my Visual C++ 2017 to run as it has run reliably for very many years? It was quite enough and adequate for me. What is happening?
I don't know what the issue is, but I have been using VS 2017 for some time and never had any such problems. And, oddly enough, I was recompiling some old graphics programs of my own only yesterday. Most of these had not been updated or built for more than two years, but all built and ran in Debug mode without problems. And without more information it is anyone's guess what the problem is. Have you tried putting a breakpoint at the very start of the code to see if it actually gets beyond the Windows framework initialisation?
-
I don't know what the issue is, but I have been using VS 2017 for some time and never had any such problems. And, oddly enough, I was recompiling some old graphics programs of my own only yesterday. Most of these had not been updated or built for more than two years, but all built and ran in Debug mode without problems. And without more information it is anyone's guess what the problem is. Have you tried putting a breakpoint at the very start of the code to see if it actually gets beyond the Windows framework initialisation?
I am trying breakpoints like you suggest. It faults at ######## in this fault printout:- _chkstk proc _alloca_probe = _chkstk push ecx ; Calculate new TOS. lea ecx, [esp] + 8 - 4 ; TOS before entering function + size for ret value sub ecx, eax ; new TOS ; Handle allocation size that results in wraparound. ; Wraparound will result in StackOverflow exception. sbb eax, eax ; 0 if CF==0, ~0 if CF==1 not eax ; ~0 if TOS did not wrapped around, 0 otherwise and ecx, eax ; set to 0 if wraparound mov eax, esp ; current TOS and eax, not ( _PAGESIZE_ - 1) ; Round down to current page boundary cs10: cmp ecx, eax ; Is new TOS bnd jb short cs20 ; in probed page? mov eax, ecx ; yes. pop ecx xchg esp, eax ; update esp mov eax, dword ptr [eax] ; get return address mov dword ptr [esp], eax ; and put it at new TOS bnd ret ; Find next lower page and probe cs20: sub eax, _PAGESIZE_ ; decrease by PAGESIZE test dword ptr [eax],eax ; probe page. ################################### jmp short cs10 _chkstk endp end
-
I am trying breakpoints like you suggest. It faults at ######## in this fault printout:- _chkstk proc _alloca_probe = _chkstk push ecx ; Calculate new TOS. lea ecx, [esp] + 8 - 4 ; TOS before entering function + size for ret value sub ecx, eax ; new TOS ; Handle allocation size that results in wraparound. ; Wraparound will result in StackOverflow exception. sbb eax, eax ; 0 if CF==0, ~0 if CF==1 not eax ; ~0 if TOS did not wrapped around, 0 otherwise and ecx, eax ; set to 0 if wraparound mov eax, esp ; current TOS and eax, not ( _PAGESIZE_ - 1) ; Round down to current page boundary cs10: cmp ecx, eax ; Is new TOS bnd jb short cs20 ; in probed page? mov eax, ecx ; yes. pop ecx xchg esp, eax ; update esp mov eax, dword ptr [eax] ; get return address mov dword ptr [esp], eax ; and put it at new TOS bnd ret ; Find next lower page and probe cs20: sub eax, _PAGESIZE_ ; decrease by PAGESIZE test dword ptr [eax],eax ; probe page. ################################### jmp short cs10 _chkstk endp end
-
I am trying breakpoints like you suggest. It faults at ######## in this fault printout:- _chkstk proc _alloca_probe = _chkstk push ecx ; Calculate new TOS. lea ecx, [esp] + 8 - 4 ; TOS before entering function + size for ret value sub ecx, eax ; new TOS ; Handle allocation size that results in wraparound. ; Wraparound will result in StackOverflow exception. sbb eax, eax ; 0 if CF==0, ~0 if CF==1 not eax ; ~0 if TOS did not wrapped around, 0 otherwise and ecx, eax ; set to 0 if wraparound mov eax, esp ; current TOS and eax, not ( _PAGESIZE_ - 1) ; Round down to current page boundary cs10: cmp ecx, eax ; Is new TOS bnd jb short cs20 ; in probed page? mov eax, ecx ; yes. pop ecx xchg esp, eax ; update esp mov eax, dword ptr [eax] ; get return address mov dword ptr [esp], eax ; and put it at new TOS bnd ret ; Find next lower page and probe cs20: sub eax, _PAGESIZE_ ; decrease by PAGESIZE test dword ptr [eax],eax ; probe page. ################################### jmp short cs10 _chkstk endp end
This is the source form of the failing section of the program: The fail happens at a breakpoint at the start of the line that starts "Main=newwindow". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{WCHAR**arg=CommandLineToArgvW(GetCommandLineW(),&nargs);
if(nargs<2) argument[0]=0;
else {int i,j=wcslen(arg[1]); for(i=0;iThe indentation has gone, sorry, because I had to send it as plain text. -
This is what the debugger outputs. The fault is presumably during a proc called _chkstk . I was not hacking or intruding into anything secret.
-
This is the source form of the failing section of the program: The fail happens at a breakpoint at the start of the line that starts "Main=newwindow". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{WCHAR**arg=CommandLineToArgvW(GetCommandLineW(),&nargs);
if(nargs<2) argument[0]=0;
else {int i,j=wcslen(arg[1]); for(i=0;iThe indentation has gone, sorry, because I had to send it as plain text.When I try to edit my message, the program text displays complete. But in the screen display it is always truncated.
-
This is the source form of the failing section of the program: The fail happens at a breakpoint at the start of the line that starts "Main=newwindow". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{WCHAR**arg=CommandLineToArgvW(GetCommandLineW(),&nargs);
if(nargs<2) argument[0]=0;
else {int i,j=wcslen(arg[1]); for(i=0;iThe indentation has gone, sorry, because I had to send it as plain text.You need to use <pre> tags around the code; either manually or use the
codebutton above the edit window. I have done it for you here. You also really should stick to only one statement per line; what you have is quite difficult to read. As to the code, I can only assume that you are doing something illegal that was not checked properly in the previous libraries. This line looks wrong for a start:else {int i,j=wcslen(arg[1]); for(i=0;i
You are usingwcslento find the length of a Unicode string, but then extracting char types. so whatever you end up with may well not be what you expect. And I am not sure that you should be callingLocalFreeon a pointer returned byGetCommandLineW; it is moderately likely that that is the cause of the problem - your stack has been corrupted. -
This is the source form of the failing section of the program: The fail happens at a breakpoint at the start of the line that starts "Main=newwindow". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{WCHAR**arg=CommandLineToArgvW(GetCommandLineW(),&nargs);
if(nargs<2) argument[0]=0;
else {int i,j=wcslen(arg[1]); for(i=0;iThe indentation has gone, sorry, because I had to send it as plain text.I concur with what Richard said. When a program fails by just disappearing instead of giving an error message, it's usually a sign of a stack overflow or other stack corruption.
The difficult we do right away... ...the impossible takes slightly longer.
-
I concur with what Richard said. When a program fails by just disappearing instead of giving an error message, it's usually a sign of a stack overflow or other stack corruption.
The difficult we do right away... ...the impossible takes slightly longer.
I found that I had an array of characters char[1024][256]. I have now changed it to char[256][256], and the bug seems to have gone away. Thanks. I am very sorry to take up your time. When I am developing a program, once in a while I make a backup copy of its source form files.
