Let me try this again. I'm wondering if there is a way to free my serial port thread after i invoke to my UI thread.
Once i Invoke from the Data Received event on the Serial port Thread to a receive function on the UI thread, my switch statement in the receive function may call a function that sends data to the pic program. Now the pic responds immediately but the data doesn't appear cause the invoke method hasn't quite exited yet. any suggestions would be Appreciated.
If you have a minute please consider upvoting this bug report as the more votes it gets, the better the chance Microsoft will actually fix it. The bug is really bad if you move std::unique_ptr values into C++/CLI there is a double-free and your application will crash.
I am working on a C++ Project in which i am using some third party SDK to read some data. Some times few API's in that third party SDK are getting crashed such that my program getting terminated\crash.
So, instead of crash i want to handle those exceptions in the third party API's. May i know how to do handle them. I am using Visual studio 2015 and used exception handling too but unable to catch the exceptions thrown by third party API's.
Thank You. As of now we are reporting the issues to the owners of the library and they are fixing and providing the fixes in their next release. But i cannot hold my work till their fix. Some how i need to proceed by excluding those exceptions in my code. Is it possible by any chance or any technique to skip those crashes and handling them in my code?
You can add generic Catch block in your code for function which is calling that third party APIs and in catch you do nothing.But its just to avoid your application from getting crash, ideally you should not do it as it makes no sense.
I am currently working on fixing a project for a client. A little information about the project first:
1. Originally developed in Visual Studio 2012 using xp_v110 build tools
2. Multiple projects in the solution
3. Currently updating/debugging in Visual Studio 2017 using VS 2015/xp_v140 build tools
4. Working on Windows 10
The application will run in debug mode, however if I just leave the application after starting the debug session (i.e. not opening/clicking on the application to open it as it starts minimized in the tray), the application crashes after 1-2 minutes.
Unfortunately the IDE is showing that the crash is taking place in chkstk.asm with the following message:
Exception thrown at 0x0064EDF9 in <<exe name="">>: 0xC00000FD: Stack overflow (parameters 0x00000000, 0x000A2000).
I have updated the exception settings to break when all C++ Exceptions are thrown, checked the box that says "Break when this exception type is thrown", and wrapped the initial method that runs in a try block, however I can never catch the error in the C++ code; it always occurs in the chkstk.asm file.
Any suggestions on how I can find out where in the C++ code the exception is occurring. Like I said, this is an update for a client and the original programmer is not available, and they never commented their code, so it is difficult enough trying to go through all this. Any help/suggestions would be greatly appreciated. Thanks in advance.
A black hole is where God tried to divide by zero.
There are 10 kinds of people in the world; those who understand binary and those who don't.
You should make small memory dump using windows task manager. If you have application .pdb files and source files you can load windows dump file with Visual studio and debug it as managed code. If there are symbols debugging files (pdb) you can see thread`s stack in appropriate state.
I suggest you launch the app in the debugger and then wait for ~20 seconds then break into the debugger. Most likely you'll see the a deep stack as it's in the midst of eating up stack space. That callstack should lead you to the issue.
It appears to use some third party library (curl ?) to obtain text input, find the first token and convert its text to an integer, which it then returns to the caller. I would suggest getting the documentation for the library and studying that.
I don't know Polish so that it is really hard to retrace the code.
But you missed some points:
There are two versions of info headers with different sizes which can be identified using the biSize member: BITMAPINFOHEADER and BITMAPV5HEADER
When biCompression is BI_BITFIELDS, these bitfields are stored after the info header.
Your code supports only 24-bit RGB bitmaps. So you should check if the file is in that format (biBitCount == 24).
You can read the pixel data from file offset bfOffBits with size biSizeImage which includes the padding bytes. But your code starts reading after the info header which is the location of the bitfields table or still within a BITMAPV5HEADER.