Printable View
I'm looking for a bug reporting script which will do the following;
1 - Ask the user for a description of the problem
2 - 'snapshot' the environment (process list, cpu config, memory etc)
3 - Either email the lot to a predefined address or store in a central DB
I can probably knock something together myself in AutoIt, but there's obviously no point in reinventing the wheel. Has anyone seen anything like this?
That would be very handy for my school as well, please let me know if you get one. It would be handy if it put the following on: Date, Time, Computer name, User logged on,
Thank You
Z
I had the same idea but have not found anything as yet. I was thinking of a system tray application that could be double clicked. Ideally this would take a screen dump of the current screen then ask the user for a description of the fault. It could then be sent along with the current workstation name, logon name, time, date and process list to a web service.
You could then have a site which showed the information from the DB.
I'm working on an AutoIt script which reports back to an SQLite DB at a network location. If anyone knows of a scriptable utility that can take screenshots (freeware of course), let me know and I'll try to include it.
Screenhunter is a free program that takes screenshots.Quote:
Originally Posted by ajbritton
The following page has a list of command line switches that are supported by the program. This sounds like it might be what you are looking for.
http://wisdom-soft.com/kb/faq_sh.htm
What about http://www.microsoft.com/windows/pro...ise/scdem.mspx - this is the "corporate" version of the error reporting which happens in Windows when a crash happens or you terminate a process etc.
It's part of the MS Desktop Optimization pack; it's not free but it's not very expensive (but I'll leave someone else to try and find out exactly how much it is ... MS licensing is not something I can face until after quite a few more beers!)
See if you can break this (needs dotNet2 & makes jpegs).
Usage: dumpscreen <filename>
@PiqueABoo: Thanks for the posting, but I should probably have mentioned that the estate of machines I need to run this script on are quite old. They will be Win2Kpro PCs with as little as 128Mb and almost certainly no .NET framework installs.
I've got a work in progress for the reporting script. At present, it does the following;
1 - On loading (at user logon), it records the computer and memory details on the SQLite DB.
2 - Creates a tray icon and sits in the background waiting for user to trigger it.
3 - When triggered, prompts for a description of the error and then logs this along with another memory status snapshot in the DB file.
When I've knocked it into shape a bit more I'll post it.
Is it possible to send the report to an e-mail address?
Z
I believe AutoIT has that functionality built in. If not, I suppose Blat would do it. It would have to be via SMTP though.
::sob:: I spent nearly FIVE WHOLE MINUTES on that!! ;)Quote:
They will be Win2Kpro PCs with as little as 128Mb and almost certainly no .NET framework installs.
Two of which were figuring out you can't attach an EXE file to a post on these forums.
It doesn't take many lines of code. A win32, not-dotNet, version would be more economical e.g. a dozen lines total and maybe three minutes. But you'd have to put the MS redistributable gdiplus.dll somewhere in the path on W2K boxes (it's already there on XP).
It's raining.
This should work without dotNet on XP. It should also work on 2K, but on that OS if you don't already have it, you need the gdiplus dll from here:
http://www.microsoft.com/downloads/d...displaylang=en
Many thanks PiqueABoo.
I don't have time to actively develop the script right now (and I think there are far more skilled developers here anyway...), so I've posted what I've got so far.
The script needs SQLITE3.DLL (download from sqlite.org) and DSWIN32.EXE (which appears to work perfectly) and GDIPLUS. I've found SQLite Expert Personal to be very useful for working on the SQLITE DB.
The script defaults to using BugLog.DB3 in the same directory as the script, but can be redirected using the INI file. The same goes for the target directory for screen dumps.