bchavez / bugtrap Goto Github PK

Currently, it seems the managed (.NET) version doesn't work with .net core. Only with .net framework.
I believe because they don't work the same. Any plan to support .net core?

I tried with an up to date version of the example "BugTrapNetTest", converted to .net 8. Nothing special to say, it just crash and don't open BugTrap.

I believe it is because of this https://stackoverflow.com/questions/75198815/why-dotnet-is-creating-a-dll-for-winforms

In a curl-based test-program I'm successfully using BugTrap to catch an exception and generate a .zip-file with a crash report. Then I try to use curl itself to upload that .zip to somewhere. An excerpt:

static const char *bt_ftp_host = "ftp://user:password@server/"; /* initialised elsewhere */
void CALLBACK ftp_put_error_log (INT_PTR unused);
void bugtrap_init (void)
{
  char buf [MAX_PATH];
  BT_SetAppName ("curl library");
  _snprintf (buf, sizeof(buf), "%s\\bugtrap-reports", getenv("TEMP"));
  BT_SetReportFilePath (buf);
  BT_SetActivityType (BTA_SAVEREPORT);
  BT_InstallSehFilter();
  BT_SetFlags (BTF_DETAILEDMODE | BTF_ATTACHREPORT);
  BT_SetReportFormat (BTRF_TEXT);
  BT_SetPostErrHandler (ftp_put_error_log, NULL);
}

void CALLBACK ftp_put_error_log (INT_PTR unused)
{
  char buf[MAX_PATH];
  _snprintf (buf, sizeof(buf), "curl -v --upload-file %s\\%s %s",
             BT_GetReportFilePath(), _what_should_be_here_, bt_ftp_host);
  printf ("executing: '%s'\n", buf);
  system  (buf);
}

My problem is how do I get the fully-qualified name of the .zip?
What is generated on runtime is c:\TEMP\bugtrap-reports\curllibrary_snapshot_160205-081001.zip. Unless I'm missing something, my feature request and question is; how can that fully qualified name (_what_should_be_here_) be returned in the callback and passed to the system() function?

Hi,
this is just a proposition, before doing a PR or not.
WaitDlg doesn't seems very revelant to the today hardware standard. It opens and closes very quickly. Seeing is just a visual "flash" with today's hardware. Of course, in the past, it was useful to keep the user waiting.

So, I propose either to delete it or to make it optional behind an enum or a preprocessor.
If removed, it also allow us to removed AnimProgressBar. If removed, it also allow us to removed AnimProgressBar and ThemeXP. And so win some kb on final dll.

On WIN10 System CSymEngine::GetOsInfo m_pszWinVersion got value "Windows 8" .

I am getting this error after adding syncfusion components to my code:

Error: Could not load file or assembly 'BugTrapN.dll' or one of its dependencies. The specified module could not be found.

Is there a known incompatibility or a workaround for this?

More and more of our returned BugTrap reports have an <address> field containing 00000000 as follows

  <error>
    <what>ACCESS_VIOLATION</what>
    <process>
      <name>Designer.exe</name>
      <id>9476</id>
    </process>
    <module></module>
    <address>0023:00000000</address>
    <function>
      <name></name>
      <offset></offset>
    </function>
    <file></file>
    <line>
      <number></number>
      <offset></offset>
    </line>
  </error>

Probably not surprisingly this causes CrashExplorer to crash.

These apparently useless reports have prompted me to look into updating from version 1.3.3718.38316 to the latest version. Can anyone offer a reason why 00000000 should could appear in an errorlog.xml file? Furthermore, if this has been a known problem, is it fixed in the latest version?

Hi,
this is just a proposition, before doing a PR or not.
We currently shipped a German translation in addition to the english.

Not sure if it is revelant to ship it by default. So I propose to remove it. Or, allow more languages. I can add French. But I am not sure if it worth it.

VersionInfo.h needs to be updated to reflect the correct version number.

BT_SetReportFormat(BTRF_XML) is ok.
minidump & report are complete.
But,
You can not create a minidump file when using BT_SetReportFormat (BTRF_TEXT) at x64 build time.
Example)

    TCHAR szBuf[1024];
GetCurrentDirectoryW(1024, szBuf);
_tcscat_s(szBuf, 1024, _T("/dump"));
BT_InstallSehFilter();
BT_SetAppVersion(_T("1.0"));
BT_SetAppName(_T("sample"));
BT_SetFlags(BTF_DETAILEDMODE);
BT_SetReportFilePath(szBuf);
BT_SetActivityType(BTA_SAVEREPORT);
BT_SetReportFormat(BTRF_TEXT);
BT_SetPreErrHandler((BT_ErrHandler)ExceptionHandler, 0);
BT_SetDumpType(0x00000001 | 0x00000040);

Hi,
this is just a proposition, before doing a PR or not.
Like the Metro Exodus (4A studio) fork of BugTrap. Add an enum to allow BTA_SAVEREPORT WITH window (currently not possible). And a "Open Folder" button who open the BT_SetReportFilePath with Windows Explorer.

So maybe a BTF_SAVEREPORT flag who do the same job than BTA_SAVEREPORT but with BTA_SHOWUI.
Implementation example:

/**
 * @brief Perform BugTrap action (show dialog, submit report, etc.).
 */
static void ExecuteHandlerAction()
{
	if (g_eActivityType == BTA_SAVEREPORT)
	{
		SaveReport(NULL);
		return;
	}
	// Create temporary report file.
	BOOL bResult = CreateTempReport();
	if (bResult)
	{
		// Process remaining actions.
		switch (g_eActivityType)
		{
		case BTA_SHOWUI:
			if (g_pResManager)
			{
                                // HERE
				if (g_dwFlags & BTF_SAVEREPORT)
					SaveReport(NULL);
                                //

				DialogBox(g_hInstance, MAKEINTRESOURCE(IDD_SIMPLE_DLG), NULL, SimpleDlgProc);
			}
			break;
		case BTA_CUSTOM:
#ifdef _MANAGED
            NetThunks::FireCustomActivityEvent(g_szInternalReportFilePath);
#else
            if (g_pfnCustomActivityHandler != NULL)
                (*g_pfnCustomActivityHandler)(g_szInternalReportFilePath, g_nCustomActivityHandlerParam);
#endif // _MANAGED

			break;
		}
	}
	// Remove temporarily generated report files.
	DeleteTempReport();
}

For the "Open Folder". What is the best? A new flag to show it (and hide the submit button). Or BTF_SAVEREPORT flag also change the button automatically.

Hi, I find that sometimes bugtrap creates dump files that seem to require the bugtrap pdb (visual studio) files in order to debug them properly. It would be great if these could be bound together with the upcoming releases. (or a method to generate the C# dlls from the user side)

In some situations, when application isn't crashed, one may need to get a stack trace for some reasons.

Well, instead of creating code that calls dbghelp.dll, one can use existing code in BugTrap.

I'm trying to modify your project in order to let screen capturing to
acquire only the screenshot of the main window of the application it
is supporting (it would be fantastic to catch all the current application's windows, but the main it's enough too). This in order not to incur privacy problems. Do you think this is feasible?

Hello,

I am using bugtrap for my C++ Unicode project and whenever I get a BugTrap Window I get only the first letter of the string I use for BT_SetAppName, BT_SetSupportEMail, BT_SetSupportURL.

Function is called like this

BT_SetAppName(L"HELLO");

CSymEngine::GetOsInfo(COsInfo& rOsInfo) uses deprecated GetVersionEx API. Applications not manifested for Windows 8.1 or Windows 10 will return the Windows 8 OS version value (6.2).

We need to find out better way to get windows version, including real major/minor versions, product type, etc.

For a workaround, I just take kernel32.dll version: GoldRenard@ab26428 In this way we don't know the real product type, so we can't detect is it server OS or client.

Currently if a user doesn't have any mail client installed, BugTrap can't send report to support email.

Is it possible to use BugTrap with BugTrapWebServer running on HTTPS?
I set the port to 443 but it failed to communicate. Still works on port 80 (HTTP) so I presume that the submitter cant talk to HTTPS?

Hello!
Is there anybody out there?

First I've (two+1) questions:
*) There is a "official" maintainer of BugTrap?
*) Who is? Is you? :-)
*) In the source code there is this old remind of a company:
2005-2009 IntelleSoft
http://www.intellesoft.net/
Are you somehow connected with this company?

I've made severale change to the project. Porting it to vs2019 and
substituted deprecated windows API (now seems to support IPV6 also).
It automatically download via nuget the last versions if
dependency (MS ATL and Boost libs).

I've also done a lot of projects changes and now is all under
one single solution for VS2019.
All build correctly.
Executable that use BugTrap have the outup directory pointing to the
output directory of the BugTrap[*].dll
All is relative to the solution path.
The postfix for ALL the .dll and filename are now:

(Debug; Release; UnicodeDebug; UnicodeRelease)
32 bit binaries: D-x32; -x32; UD-x32; U-x32
64 bit binaries: D-x64; -x64; UD-x64; U-x64

(Debug; Release)
32 bit NET binaries(only Unicode): ND-x32; N-x32
64 bit NET binaries(only Unicode): ND-x64; N-x64

I've not tested the managed and the C# Test program.

Anyway...let me know if you are interested and if you
can to give a look and eventually merge my effort.
Cheers.

Fabio Sguanci

@bchavez

Hi, I've been using bugtrap very well for my c++ applications, and was trying to use Bugtrap for my .net applications as well. I'm however getting the error that .net versions of 2.0.5 are incompatible with those of 4.0 - it would be great if BugTrap could be updated to fit newer systems.

(4.0 is the last supported by XP)

When building the VS2008 solution (and possibly others) a minimum of Windows SDK v7 is required. This manifests itself as failure to find VER_SUITE_WH_SERVER when building. In my case changing the VS2008 from v6 to v7 solved the problem

WTL seems to be a pre-requisite for building. I couldn't find this mentioned in the documentation, but maybe I missed it.

The project and/or solution files mention the $platform and $configuration macros, these should be $platformname and $configurationname otherwise the various build overwrite each other

When building for, say, DEBUG, the client code links against zlibSD.lib but the zlib build only produces zlib.lib. Changing the output name approriately for a given build solved this.

It could be that I'm being naive about the above issues, but it seems as though building using CI scripting doesn't guarantee that the IDE builds will work without tweaking. :-(

`#include <Windows.h>
#include "BugTrap\BugTrap.h"
#include

#pragma comment(lib, "BugTrap\BugTrapU.lib") // Link to Unicode DLL

void SetupExceptionHandler();

int main()
{
SetupExceptionHandler();
BT_SetTerminate();

std::map<int, int> idMap;
idMap[0] = 1;

idMap.erase(idMap.begin());
idMap.erase(idMap.begin()); // BugTrap cannot capture this exception with my pc and environment
//int* ptr = 0; *ptr = 0; // BugTrap can capture this exception

return 0;

}

void SetupExceptionHandler()
{
BT_InstallSehFilter();
BT_SetFlags(BTF_DETAILEDMODE | BTF_EDITMAIL);
}`