Click here to Skip to main content
15,867,568 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Rebuilt some old code, and executed a portion to open a file. In all the years before there were no issues opening files, and the last good production build of the program executes properly without any issues in that area, *and* I didn't make any changes in that part of the code. The rebuilt version gives an 'Exception thrown at ____ reading location 0xFFFFFFFC' in wntdll (Visual Studio 2015) in both Debug and Release versions. If I continue it twice, it executes as expected. Open another file without closing the program and there are no more exceptions thrown. If I execute the debug or release version directly from Explorer I don't get a crash, and it works as expected.

Any ideas? Leave it knowing that it seems to work everywhere except in VS? The only thing I can think of is that something within Windows has changed since the code last executed correctly in VS. But that is just because I'm tired of looking at it. The newest test code that gives the exception (recreated almost scratch from an online sample, and stripping from the class it is in) is the following:

C++
TCHAR filePtrC[MAX_PATH];

bool openDialog() {
   OPENFILENAME tofn = { 0 };
   tofn.lStructSize = sizeof ( tofn );
   tofn.hwndOwner = NULL;
   tofn.lpstrFile = filePtrC;
   tofn.nMaxFile = MAX_PATH;
   tofn.lpstrFilter = L"All\0*.*\0Text\0*.TXT\0";
   tofn.nFilterIndex = 1;
   tofn.lpstrFileTitle = NULL;
   tofn.nMaxFileTitle = 0;
   tofn.lpstrInitialDir=NULL;
   tofn.Flags = OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST;
   return (GetOpenFileName(&tofn) == TRUE); //Exception thrown here.
   }


What I have tried:

Cussing. Fist shaking. The first and second stages of the five stages of acceptance. More cussing. Multiple revisions to the above code. And more cussing, for good measure.
Posted
Updated 2-Feb-20 0:45am
v2
Comments
Richard MacCutchan 2-Feb-20 7:31am    
Are you sure that your project properties specify Unicode? If not then your filter string may well be incorrect. As Carlo says, you should use the _T macro rather than the L prefix on your strings.
David O'Neil 2-Feb-20 16:49pm    
Thank you. Both projects in the solution are set for Unicode. Changing it to the _T macro didn't make a difference. But it was worth a shot!
Richard MacCutchan 3-Feb-20 4:27am    
That, and your comments above, suggest the the problem may well be caused by some code that is not part of the above function. A bad address somewhere else could quite easily corrupt something that leads to the exception. But finding such a bug is never easy.
David O'Neil 3-Feb-20 12:06pm    
The realist in me thinks that, too. I just don't want to listen to him! I remember how hard it was last time to track one of those down! Stripping away a piece at a time... Uugh!
Richard MacCutchan 3-Feb-20 12:23pm    
If you use the debugger, then when the exception hits the stack trace may help.

1 solution

I made a test with your code on my system. With Visual Studio 2019 both Release and Debug build (both for x86 and x64) run fine.
So, yes, it looks there is actually some trouble withe the Visual Studio installed on yout system.
By the way, I would have used _T instead of L, but it really doesn't matter.
 
Share this answer
 
Comments
David O'Neil 2-Feb-20 16:41pm    
Thank you for trying. It encouraged me enough to try the 'Fix' option in the VS installer. Still gives an error. So I downloaded and installed 2019 and built the project with it. It still gives the same issues (or at leas the first execution did the same thing as before).

So either my Windows installation has something screwy in the core (because of the 1903 update?, which did occur between the good and bad runs), and needs reinstalled, or changes to other parts of my framework have a bug somewhere. Yay! I'll try building it on another computer and seeing if that works. I don't relish the thought of reinstalling everything.

Again, Thanks!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900