Jose's API Headers III 1.05

[Dan English]

I don't suppose there's a chance Jose would allow version 1.05 of his API Headers on here is there?

I've got the copy linked from the latest FireFly releases thread (http://www.planetsquires.com/protect/forum/index.php?topic=3413.0), which I believe is a year or so older.

Whenever I include wininet.inc in one of my new PBWin projects, the program crashes.  Commenting out wininet.inc allows the program to run again.

I'm wondering if the newer version might help!

[José Roca]

There is no newer version.

Including "wininet.inc" in my programs doesn't make them to crash.

We need more info.

[Dan English]

This is indeed strange -- I do realize simply including it shouldn't cause the crash.

My program compiles ok without this line:

Code Select Expand

#INCLUDE ONCE "wininet.inc"

But when I add it, I get an APPCRASH in PBWin.exe.

More details on the crash:

Code Select Expand

Problem signature:
  Problem Event Name: APPCRASH
  Application Name: PBWin.exe
  Application Version: 0.0.0.0
  Application Timestamp: 713a4150
  Fault Module Name: PBWin.exe
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 713a4150
  Exception Code: c0000005
  Exception Offset: 000427ac
  OS Version: 6.1.7601.2.1.0.768.3
  Locale ID: 4105
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt

[José Roca]

Could be caused by an antivirus program.

[David Kenny]

Dan,

Jose is right, it's highly unlikely the include file itself.

Your first post indicated that your program crashed.  The second post says that PBWin.exe crased (presumably when it was compiling your sourcecode).  I am guessing that the second post is what you actually meant? 

You also didn't mention FireFly, but since you are posting here I am assuming that it is a FF project?  If so, where did you place the #Include directive?  Paul recommends putting includes that don't  need to be parsed by FF in FF_AppStart. 

Also, I would recommend just changing up the order of your includes as a test.  Not guaranteed to fix it, but I had a similar situation a couple years ago (I don't believe it was a FF project) where the compiler was crashing, as it is with you, when I added an include.  I placed the include file in a different spot and the compiler didn't crash.  I didn't try to trouble shoot it further, so I can't tell you any more about what the cause was.  Properly written, nothing should cause the compiler to crash.  It should throw an error message and quit gracefully. You have likely just created a situation that never showed up in all the beta testing done on each PB version.

It is also helpful to know what version of FF, PB, and sometimes even the OS\service pack you are using when something like this happens.

David

[Dan English]

Sorry -- this thread slipped my mind, so I forgot to follow up!

This is purely a PBWin 10 app that uses Jose's headers; no FireFly.  I do have FireFly for other projects though, and this is where I get my copy of Jose's header files.  As such, I thought maybe there was a newer version available that could have been made available on this board.

I've moved on and found an alternative method of doing things, but I intend to get back to this issue.  I'll move the includes around and see if that makes a difference.

Thanks!

[David Kenny]

Dan,

As I stated, the compiler shouldn't crash with anything you give it.  If you code is not too proprietary, you might consider sending it to the support guys at PB.  They should be interested in looking at it to determine how it crashes their compiler. 

[Paul Squires]

I wonder if it is the built in resource compiler that is crashing the program? I can't remember the last time I ever got the Windows compiler to crash, but I know of many times when the resource compiler would. Maybe something in the include file is conflicting with something in PB's implementation of the resource compiler. Who knows. Interesting problem you are seeing.

[Cho Sing Kum]

I did a search for "Exception Code:   c0000005" and it appears this is a very common error that may be triggered unexpectedly by any program. Reading through the search result, while the reasons can be many, it all point to access violation of memory.

Two links I like to highlight may throw some light:
http://blogs.msdn.com/b/calvin_hsia/archive/2004/06/30/170344.aspx
http://www.youtube.com/watch?v=oJ0hz9JkLgM

Also can be anti-vrus:
http://forums.2k.com/showthread.php?90164-How-to-fix-Exception-Code-c0000005

Even Excel 2007 running in compatibility mode can also cause this error:
http://www-01.ibm.com/support/docview.wss?uid=swg21643715

[David Kenny]

Dan,

You could probably narrow it down quite a bit by compiling on a second machine.  If it still crashes on another machine, it's likely a compiler bug. 

Cho,
The first link is about c0000005 crashing when you are running an executable, not when you are compiling it.
The second link refers to things that wouldn't be influenced by what Include file you add or don't add.
While I would stop short of saying it's definitely not anti-virus, I would rule that out as it would be unlikely that a crash is triggered only when compiling with that particular Include file.  And, don't run Excel 2007 in compatibility mode... 

The resource compiler would be similarly unlikely as the that Include wouldn't change the the resource profile of a program.

My suggestion regarding PB support might be slow or even futile with the current state of PB (the company) at this time. (edited by the Department of Redundancy Department)

David

[Knuth Konrad]

Cho,
The first link is about c0000005 crashing when you are running an executable, not when you are compiling it.

Think a bit about that statement. When you compile a program, the compiler is a running executable.

[David Kenny]

Knuth,

Please...     I am assuming you are joking, as you are stating the obvious.  So obvious, in fact, I chose not to mention that.  Because the article is  about the code crashing after it is compiled.  Not causing the compiler to crash while compiling the code.  What you are talking about would be an article about a compiler bug.

[Dan English]

Dan,

You could probably narrow it down quite a bit by compiling on a second machine.  If it still crashes on another machine, it's likely a compiler bug. 

Well I just tried compiling the same code on my day-job computer..... and the exact same PBWin.exe crash occurred.  These two computers have different AV products installed (MSSE vs Kaspersky).

Just to further experiment, I replaced wininet.inc (which PBWin is crashing on) with a couple other random Jose include files:  bcrypt.inc, htmlhelp.inc and tvout.inc.  These all worked fine.  So far it seems wininet.inc is the only one causing PBWin trouble.

[David Kenny]

Good test.  But I'm still asserting that, while adding wininet.inc to your program creates the right condition for PBWin to crash, it is most likely a compiler bug. 
A) It has to be a combination of your program and wininet.inc or other people would have reported a problem to Jose.   
B) If A is false, and it's just bad code/data in wininet.inc then PBWin should tell you so.  To crash instead is, by definition, a bug.

If you think about it, there is not any documented way for your code to be able to make the compiler access memory outside it's address space. A compiler crashing is never the fault of your code or any Includes.  If there is a problem with any code you run through it, one of its main jobs is to catch it and report it to you.

I did repeat myself a bunch here, but I'm having difficult figuring out how to explain it concisely. So I have resorted to paraphrasing.

David

[James Padgett]

Dan,

You could probably narrow it down quite a bit by compiling on a second machine.  If it still crashes on another machine, it's likely a compiler bug. 

Well I just tried compiling the same code on my day-job computer..... and the exact same PBWin.exe crash occurred.  These two computers have different AV products installed (MSSE vs Kaspersky).

Just to further experiment, I replaced wininet.inc (which PBWin is crashing on) with a couple other random Jose include files:  bcrypt.inc, htmlhelp.inc and tvout.inc.  These all worked fine.  So far it seems wininet.inc is the only one causing PBWin trouble.

You have something else that is wrong... remove sections of your code such that you can remove all includes except wininet.inc ...
run the compile from the command line ??
Run  your dev evironment via depends .... ??

What everyone is saying is that ' it can't be  your wininet.inc ' that is causing your problem...  more likely it is simply revealing a problem somewhere else..

Create a new app with only the wininet.inc sections in it... try again ...