C / C++ / MFC

Re: CInternetSession: https certificate problem

13-Oct-10 6:19

Maybe this[^] can help.

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

msn9214-Oct-10 4:49

msn92

14-Oct-10 4:49

Code-o-mat, thanks for your reply.

I tried the code that should ignore the invalid certifacate as said in the link you gave.
But, it doesn't seem to work, the code's working, but my problem didn't get solved.
Please see the code:

CFile* f=NULL;
MyTry:
try{
	f=(CFile*)ises.OpenURL(L"https://mysite.com/login.jsp");
}
catch(CInternetException* s){
	if(s->m_dwError==ERROR_INTERNET_INVALID_CA){
	    DWORD dwFlags;
	    DWORD dwBufferLen=sizeof(dwFlags);
	    ises.QueryOption(INTERNET_OPTION_SECURITY_FLAGS,(LPVOID)&dwFlags,&dwBufferLen);
	    dwFlags|=SECURITY_FLAG_IGNORE_UNKNOWN_CA|SECURITY_FLAG_IGNORE_CERT_CN_INVALID;
	    ises.SetOption(INTERNET_OPTION_SECURITY_FLAGS,&dwFlags,sizeof(dwFlags));
	    goto MyTry;
	}
}
...

Is there any other way to workaround this problem?

Re: CInternetSession: https certificate problem

Code-o-mat14-Oct-10 5:21

Painfully frustrating sdk memory exception? [modified]

14-Oct-10 5:21

I can't think of anything else other than trying to do the download without OpenURL, using CInternetSession::GetHttpConnection[^], CHttpConnection::OpenRequest[^] and CHttpFile[^], maybe it makes a difference...

Remove Maximize

john563213-Oct-10 5:20

john5632

13-Oct-10 5:20

Hi,

How to remove maximize button from frame window in SDI application?

Re: Remove Maximize

Aescleal13-Oct-10 5:43

Aescleal

13-Oct-10 5:43

I've never found a clean way to remove the maximise button but you can effectively disable it by handling WM_SYSCOMMAND/SC_MAXIMIZE and returning 0 from the window procedure.

Cheers,

Ash

Re: Remove Maximize

Emilio Garavaglia14-Oct-10 4:14

Emilio Garavaglia

14-Oct-10 4:14

Better to rest the WS_MAXIMIZEBOX style bit with a SetWindowLong, so that the gui will paint the button consistently.

By simply throwing away the command, you end-up with an inconsistent GUI showing an enabled command that doesn't behave as expected.

2 bugs found.
> recompile ...
65534 bugs found.
D'Oh! | :doh:

Re: Remove Maximize

Alain Rist13-Oct-10 6:28

Alain Rist

13-Oct-10 6:28

Don't set (or remove ) the WS_MAXIMIZEBOX style. As Ash said, the maximize box will then be drawn disabled.
If you have none of WS_MAXIMIZEBOX and WS_MINIMIZEBOX styles, no size boxes are drawn at all.
cheers,
AR

When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)

fjdiewornncalwe13-Oct-10 1:47

13-Oct-10 1:47

I have a very frustrating issue that has been driving me nuts for a couple of years now.

We have a 3rd party application that is pretty much a high load Sybase database to which we have no visibility. My internal customer requires me to provide them with real time statistics using a web app to show the results.

In order to retrieve this real time data, we have an sdk provided by the vendor, who unfortunately no longer exist so it is completely unsupported.

This sdk has one big problem, it has a memory leak that causes the thread to grow by between 2 and 4k on each iteration.

My solution is an MFC application which consumes the sdk. In order to manage the memory space of the application and keep it from eating up unlimited resources, I have a Windows Service wrapping the application and monitoring the memory usage. When the usage gets to big, it signals the application to exist and then restart.

My issue is that periodically there is a memory error occuring within the sdk which I can't handle in my application. There is no pattern to the timing of this error. It could be five minutes, or five days, and the invalid memory address also doesn't follow any visible patterns.

Has anyone else had a similar issue with a memory exception in a third party sdk? How did you deal with it? I have spent years writing real time software and my threading knowledge is very good, so I have eliminated the possibilities of bad or missing locks and pointers in my side of the application.

modified on Wednesday, October 13, 2010 2:27 PM

Sauro Viti13-Oct-10 2:33

Sauro Viti

13-Oct-10 2:33

If the memory leak and the memory access error are inside a third-party library that comes without sources, you have no chance to fix it. According to what you have already done, the only one approach that I could imagine is to use Structured Exception Handling (C++)[^] to catch the memory access violation event: this will give you the chance to exit the application without showing a dialog that reports the crash, the next step is obviously to restart the application.

fjdiewornncalwe13-Oct-10 3:13

13-Oct-10 3:13

Thanks for the quick response. I'm doing some reading and I'll post back whether this is a solution or not.

Maximilien13-Oct-10 5:47

Maximilien

13-Oct-10 5:47

PogoboyMtK wrote:
we have an sdk provided by the vendor, who unfortunately no longer exist so it is completely unsupported.

After patching a solution, have a long hard discussion with the power that be in your company to find a replacement for that faulty SDK.

Watched code never compiles.

fjdiewornncalwe13-Oct-10 5:54

13-Oct-10 5:54

I agree 100%. My issue is that the sdk is tied 100% to the db which is 100% tied to the product which is 100% tied to the users which is simply not an option to upgrade.. I don't know whether to laugh or cry about that one.

Code-o-mat13-Oct-10 5:59

Re: Bloody sdk memory exception? [modified]

13-Oct-10 5:59

This might sound disgusting but maybe you could try hooking the memory allocation API calls "under the hood", i mean things like GlobalAlloc or HeapAlloc and somehow keep track of the memory allocation/deallocations the third party does and when you get back the control (so execution comes back from the third pary call), investigate what memory allocations were left undeallocated and deallocate them yourself.

I already did such hooking magic a few times in my life so in case you are interested, i am willing to try and help doing this, it sounds like a challenge. Smile | :)

fjdiewornncalwe13-Oct-10 8:35

Re: Bloody sdk memory exception? [modified]

13-Oct-10 8:35

I would love for the help, but due to confidentiality issues I can't take you up on it.
Thank you for the offer, though.

Anytime someone tells me some code will be "disgusting" or "really ugly", etc. I become very much intrigued by the challenge of making it pretty and manageable.

modified on Wednesday, October 13, 2010 2:52 PM

Code-o-mat13-Oct-10 10:23

13-Oct-10 10:23

I didn't mean the code would be ugly, i meant the concept itself. Anyways, i can still try to give you the idea, maybe you can use it, maybe not, that is up to you to decide, so here's what i would do.

1. Try to determine where the memory leaks come from by trial and error (i mean, what 3rd party call, i supose you already know that, so you can skip this step)
2. Install hooks for the allocation/reallocation/deallocation methods listed here[^], see API hooking revealed[^] for hooking methods (since you are working within your own process -i supose- you don't need the DLL injection part). Depending on that SDK you might need to do the hooking for multiple modules (DLLs), again, this is up to you to determine. Since malloc/new come down to these memory management functions, this should suffice to "catch" all memory allocations.
3. In my hook functions, i would call the originals to perform the actual memory management, but i would add every allocated pointer to some array of my own, remove them when they are freed, replace them when reallocations are done. I would make this conditional based on some global flag (or such) so when it is unneeded (when no 3rd party code is executing) it doesn't take up resources uselessly.
4. Before the 3rd party call, i would turn the "allocation tracking" mentioned in point 3, let the 3rd party thing finish, turn off the tracking thing, and then analize the array i used for the pointers. If my assumptions are correct the array should contain pointers to the buffers which aren't freed up and then i could just free them up myself (be careful to use the correct methods for the deallocation, so if e.g. a pointer was allocated by HeapAlloc then use HeapFree, if VirtualAlloc then use VirtualFree).

What might go wrong is that if the 3rd party thing e.g. calls CRT's malloc, and that calls HeapAlloc, which in turn calls VirtualAlloc, and you hooked both HeapAlloc and VirtualAlloc, then you might "hit" the same pointer twice, another thing that can be -and i am afraid will be- a problem is that -as far as i know- CRT doesn't actually free up memory when you call free (or at least not always) but it somehow flags it internally for himself to be free and will reuse it later, sadly as far as i know you can't hook malloc/free.

This whole idea requires some experimenting i am afraid. In case you decide to try it, please do tell me how it went, i am curious. Good luck, if you should have any questions, feel free to hit me in the head with it. Smile | :)

[EDIT] If your third party SDK doesn't link statically to CRT (so uses the DLLs) then you might even hook malloc/free/realloc too. [/EDIT]

modified on Wednesday, October 13, 2010 4:47 PM

fjdiewornncalwe14-Oct-10 2:30

14-Oct-10 2:30

Code-o-mat wrote:
feel free to hit me in the head with it

I might take you up on that. I'm tired of doing it to myself all the time. Smile | :)

Code-o-mat14-Oct-10 2:55

14-Oct-10 2:55

I'll just put on my headbanging helmet... Smile | :)

Code-o-mat25-Oct-10 0:13

25-Oct-10 0:13

Hey, sorry for being nosey but i am just curious, could you solve this problem in the end, and if yes, how did you?

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <

fjdiewornncalwe25-Oct-10 4:26