I'm stuck trying to debug a problem which only occurs on my machine. It doesn't exhibit on any of the other devs' systems, nor on our production test server. I've tried pretty much everything I can think of short of completely wiping my hard disk and starting from scratch, or sneaking into the office in the middle of the night to swap my computer with someone else's.
This brings to mind the titular question, then: short of those drastic measures, what do you do when trying to resolve issues that no one else has? I'm open to advice that's general or specific.
[Not sure if this should be CW or not.]
Have you attached a debugger to the program to find the exact point of failure? That is what I would do first.
Sometimes third party software can be the root cause of these sorts of issues. Things like Anti-virus software install low-level filesystem and network drivers that can cause random intermittent failures. You can try killing all processes that aren't base OS services and your app.
Depending on your OS there are different tools that you can use to see what's going on under the covers. E.g. on Windows you can use Process Monitor to see what Registry keys it opens, what DLLs get loaded, etc. You can run this on your machine and on the success machines and compare to see if perhaps some required module is missing .
But seriously, use a debugger. That's what they are there for.
Two things:
I start with the obvious: What's different on your box? More memory? Odball PCI card? Different Microsoft APIs or service packs?
For oddball random software and/or OS crashes:
Check your system for heat issues.
Check your RAM for bad bits.
In this situation, I would try to check out the code and cleanly rebuild it from a different directory to make sure that there are no miscellaneous files in your working directory that are causing a problem.
If you are doing work against a database, I would also try tearing down the database and reconstructing it, possibly using a dump from another developer's machine.
Check the versions of any external third party software - database version, OS version, even software patches.
Look at the configuration on someone else's machine who doesn't have the problem and compare.
Get another developer to sit at your workstation and try to reproduce the problem and also go to their workstation and try it. True story - a fellow developer had a bug that he could only reproduce on his machine...it turns out that he was doing something slightly different in the GUI that no one else was doing (tabbing to a button and then hitting enter, everyone else just hit enter). It never occurred to him that other people might just hit enter to submit, because that "didn't make sense" to him.
Related
I have a malicious .scr file which i heard steals your gaming account items. Is there a way to debug this .scr file in safe environment without executing it. I opened it in IDA PRO but did not find it much useful.
Any pointers regarding the debugging process will be highly appreciable.
Analysis of malware is risky. If you are committed you at least need a Linux host with Windows guest on a sacrificial computer that doesn't have a wireless card and is unplugged from internet. Malware often has a mechanism to detect the jail. Common VMs use standard drivers and checking if running in jail is easy. If in jail then do nothing is a one line of code. To make matters worse, decent malware often has a mechanism to jailbreak from a VM and infect host Windows. Don't even mention Sandboxie. Last, but not least - some malware starts revenging if you try to decompile it. So, instead of just a stolen game password you might have a big mess.
So, if you have a sacrificial computer and free time, then go ahead. But do it carefully.
First: DEBUG a program means that you execute it, so if you know that the program is a malware you should do it in a safe enviroment like a virtual machine.
Malware usually use to protect themselves from debuggers, so this kind of job needs so many skills.
A kind of analysis that you can do is to execute the malware in a virtual machine and take a snapshot of the machine, then analyze the dump with Volatily and see what connections have been made by the system, the state of process etc..
So I have used Cygwin on and off for the past few years and I've installed it a handful of times. However, I've never experienced the install hanging during the install process. When this happens, the install literally freezes and doesn't budge a "bit." I've read that this is a somewhat common problem but like I said, I've never come across it before.
Here's a play-by-play of what I'm doing and where it hangs on me.
Download the Setup-x86.exe from http://cygwin.com/install.html
Install from Internet
Use "C:\cygwin" as the default root directory for all users.
Use "C:\Users\Austin\Downloads" as the default local package directory
Direct Installation
Use http://mirrors.kernel.org per this question.
I don't specify any additional items for the install (I thought it would best to keep it as simple as possible after running into this problem multiple times.)
I don't change any of the "Resolving Dependencies" (whatever those are)
...and everything goes great until a certain package get's tripped up and causes the install to hang. This is almost always a different package at a different point in the install. In this instance, it was texinfo-5.2-1.tar.xz and the install was at 94%! So close!!!
So what I'm looking for is how do I help the installer continue from this point? What do I need to do to go in cygwin and give it the extra motivation it needs to finish the job.
Work around to the problem above:
So after fiddling with the install a little more, I discovered that if you close the frozen install, and re-execute the setup file, it forces the install past the point where it got snagged the previous time. For example, after canceling the snagged install at 94% (mentioned above), I ran the setup file again and got to 95% before the install snagged again. I repeated this setup about 5 times before successfully installing cygwin.
Like I said, this is just a work around and may be the best/only solution.
I had the exact same problem on my Win7 64 bits with the 64 bits installer. I successfully solved the problem by deleting the content of
c:\[cygwin_install_dir]\var\log
Which contained two files:
setup.log
setup.log.full
Restarted the installer and everything went well!
Hope this will help.
https://cygwin.com/faq.html#faq.setup.hang
I turned off my anti-virus software and the install proceeded through with no problems.
I want to share my solution which worked. BTW, I tried all the solutions listed here and could not solve.
Open Task Manager
Kill any dash.exe or bash.exe
Run Cygwin installation.
Make sure to use default install path. Somehow changing
it did not work for me.
Get to the first stuck point
When it is stuck at *.dash, kill dash.exe
When it is stuck otherwise, kill bash.exe
Then it will lead to successful setup.
I fixed the same type of problem installing CYGWIN on Windows 8 by turning off my firewall. The hang up disappeared and I had no problem after that.
Something that also worked for me, suggested from the cygwin mailing list, was doing a full rebase as follows:
Run /usr/bin/rebase-trigger full on the cygwin terminal
Reboot and terminate any cygwin-related processes and services
Run the the setup again
Look out for BLODA (Big List Of Dodgy Apps.) and uninstall
BLODA - A list of applications that interfere with the normal working of Cygwin by intrusively injecting themselves in the system call chain
https://cygwin.com/faq/faq.html#faq.using.bloda
What applications have been found to interfere with Cygwin? >>>
From time to time, people have reported strange failures and problems in Cygwin and Cygwin packages that seem to have no rational explanation. Among the most common symptoms they report are fork failures, memory leaks, and file access denied problems. These problems, when they have been traced, often appear to be caused by interference from other software installed on the same PC. Security software, in particular, such as anti-virus, anti-spyware, and firewall applications, often implements its functions by installing hooks into various parts of the system, including both the Explorer shell and the underlying kernel. Sometimes these hooks are not implemented in an entirely transparent fashion, and cause changes in the behaviour which affect the operation of other programs, such as Cygwin.
Among the software that has been found to cause difficulties are:
AR Soft RAM Disk
ATI Catalyst (some versions)
AVAST (disable FILESYSTEM and BEHAVIOR realtime shields)
Avira AntiVir
BitDefender
Bufferzone from Trustware
ByteMobile laptop optimization client
COMODO Firewall Pro
Citrix Metaframe Presentation Server/XenApp (see Citrix Support page)
Credant Guardian Shield
Earthlink Total-Access
Forefront TMG
Google Desktop
Iolo System Mechanic/AntiVirus/Firewall
Kerio, Agnitum or ZoneAlarm Personal Firewall
LanDesk
Lavasoft Web Companion
Lenovo IPS Core Service (ipssvc)
Lenovo RapidBoot Shield
Logitech webcam software with "Logitech process monitor" service
MacType
NOD32 Antivirus
NVIDIA GeForce (some versions)
Norton/McAfee/Symantec antivirus or antispyware
PC Tools Spyware Doctor
Panda Internet Security
Sonic Solutions burning software containing DLA component (when DLA disabled)
Sophos Anti-Virus 7
Spybot S&D TeaTimer
Various programs by Wave Systems Corp using wxvault.dll, including Embassy Trust Suite and Embassy Security Center
Webroot Spy Sweeper with Antivirus
Windows Defender
Windows LiveOneCare
IBM Security Trusteer Rapport (see its home page
Sometimes these problems can be worked around, by temporarily or partially disabling the offending software. For instance, it may be possible to disable on-access scanning in your antivirus, or configure it to ignore files under the Cygwin installation root. Often, unfortunately, this is not possible; even disabling the software may not work, since many applications that hook the operating system leave their hooks installed when disabled, and simply set them into what is intended to be a completely transparent pass-through mode. Sometimes this pass-through is not as transparent as all that, and the hooks still interfere with Cygwin; in these cases, it may be necessary to uninstall the software altogether to restore normal operation.
Some of the symptoms you may experience are:
Random fork() failures
Caused by hook DLLs that load themselves into every process in the system. POSIX fork() semantics require that the memory map of the child process must be an exact duplicate of the parent process' layout. If one of these DLLs loads itself at a different base address in the child's memory space as compared to the address it was loaded at in the parent, it can end up taking the space that belonged to a different DLL in the parent. When Cygwin can't load the original DLL at that same address in the child, the fork() call has to fail.
File access problems
Some programs (e.g., virus scanners with on-access scanning) scan or otherwise operate on every file accessed by all the other software running on your computer. In some cases they may retain an open handle on the file even after the software that is really using the file has closed it. This has been known to cause operations such as deletes, renames and moves to fail with access denied errors. In extreme cases it has been known for scanners to leak file handles, leading to kernel memory starvation.
Networking issues
Firewall software sometimes gets a bit funny about Cygwin. It's not currently understood why; Cygwin only uses the standard Winsock2 API, but perhaps in some less-commonly used fashion that doesn't get as well tested by the publishers of firewalls. Symptoms include mysterious failures to connect, or corruption of network data being sent or received.
Memory and/or handle leaks
Some applications that hook into the Windows operating system exhibit bugs when interacting with Cygwin that cause them to leak allocated memory or other system resources. Symptoms include complaints about out-of-memory errors and even virtual memory exhaustion dialog boxes from the O/S; it is often possible to see the excess memory allocation using a tool such as Task Manager or Sysinternals' Process Explorer, although interpreting the statistics they present is not always straightforward owing to complications such as virtual memory paging and file caching.
I was able to get this to work - mine was just stuck on 0/Perpetual with no progress bar. It was Windows defender, I added my cygwin folder (C:\cygwin64) into the exceptions for windows defender and progress started immediately.
I have some customers/candidate who complained that my program doesn't work on their Windows 7 64 bit version (confirmed with screenshots). The errors were strange, for example:
in the trial version i am
getting a error message whenever i
click on \"mark\" \"delete\" \"help\".
error msg is: Access violation at
address 0046C978 in module
\'ideduper.exe.\' read of address
00000004
windows 7 ultimate 64bit. i7 920
#2.67GHz 9gb or ram
'Mark', 'delete' and 'help' are just standard TToolButton on TToolbar.
The other example is failing to get a thumbnail from IExtractImage.
I have told them to try Compatibility mode but still doesn't work.
The problem is when I tested it on Windows 7 HP 64-bit on my computer (which I've done it before released it actually) it just works fine! So I don't know what causing it
Do you have any advice ?Are different Windows package (home basic,premium,ultimate,etc) treating 32 bit prog differently ?Are the newer version of Delphis (I use 2006) more compatible with 64 bit Windows ? Do I need to wait until 64 bit compiler out?
Thanks in advance
Your best bet in my opinion is to add MadExcept or EurekaLog or something similar to your application and give it to the customer to try again. MadExcept will generate log with stack trace, which will give you a clearer view of what is happening there.
To answer 2nd part of the question, 32bit Delphi programs work fine on 64bit Windows 7. I think it's more likely you have some memory management problems and the customer just happens to stumble upon them while you don't. Use FastMM4 to track those down.
Your applications is trying to access an invalid pointer. Changing environment may surface issues that are hidden in others. Check your application, and use FastMM + JCL+JCVL/MadExcept/EurekaLog to get a detailed trace of the issue. Some Windows APIs may have some stricter call requisites under 7 and/or 64 bit, but we would have to know what your app actually cals.
A free alternative to MadExcept is JCL Debug stuff. However it is less thorough and doesn't include the cool dialog box to send the stack trace to you via email, or as a file you can attach and manually email.
MadExcept is worth the money, and it is free for non-commercial use. You could try it first on your own PC, observe its functionality, and be sure it functions the way you want, and then buy it.
If buying Delphi is worth it (and it is!) then buying mad Except is a no brainer. But if you insist on rolling your own, JCLDebug (part of jedi code library) is also pretty nice.
Give them a stripped down version of your app and see when the problem goes away. I am betting it is your code as I never had any problems with my (hundreds of) W7/64 clients.
I'd be willing to bet it's an issue in your code. The reason it's failing on your customer's machine and not yours is that your machine probably has the default Data Execution Protection (DEP) enabled (which is turned on only for essential Windows programs and services), while your customer's computer is actually using DEP as intended (turned on for all programs and services).
The default setting (which is compatible with older versions of Windows, like 95/98/ME), allows software to execute code from what should be data segments. The more strict setting won't allow this, and raises a system-level exception instead.
You can check the settings between the two by looking at System Properties. I'm not at a Win7 machine right now, but on WinXP you get there by right-clicking on My Computer, choosing Properties, clicking on Performance Options, and then selecting the "Data Execution Prevention" tab. Find it on Vista/Win7 by using the Help; search for Data Execution Protection.
The solution, as previous answers have told you, is to install MadExcept or EurekaLog. You can also get a free version as part of JEDI, in JCLDebug IIRC. I haven't used it, so I can't vouch for it personally. I've heard it's pretty good, though.
If you don't want to go that route, set a breakpoint somewhere in the startup portion of your app (make sure to build with debugging info turned on). Run your app until the breakpoint is hit, and then use the IDE's Search->Goto Address (which is disabled until the breakpoint is hit). Enter the address from the exception dialog (not the one that's almost all zeros, but the 0046C978 address, prefixed with $ to indicate it's in hex) as in $0046C978. You'll probably end up in the CPU window looking at assembly code, but you can usually pick out a line of Delphi code of some sort that can sometimes give you a place to start looking.
In addition to all previous suggestions, I'll add the difference in accessing Registry under WOW64 compared to Win32. If your application is accessing Registry to read or write some settings, you should be aware of this. First, take a look at this and this page in the MSDN. On this page you will find 2 flags that determine the access you get to Registry from 32- or 64-bit application. KEY_WOW64_64KEY is the one that you should use.
In any case, I agree with others about using madExcept (or any other similar tool) to be able to find the exact cause of your problems.
I need some "light" to get a solution. Probably there are tons of things that cause this problem, but maybe somebody could help me.
Scenario: a Windows server running 24/7 a PostgreSQL database and others server applications (for processing tasks on database, etc...). There are differents servers scenarios (~30), with different hardware and windows versions (XP SP3/ WinServer, etc... all NT based). All aplications were written in Delphi7, and link to DLLs (in D7 also).
After some days (sometimes a week, sometimes a couple of months), Windows begins to act strange, like not opening start menu, some buttons are missing in dialogs. And soon some applications do not open, raising a event on eventviewer:
Faulting application x, version y, faulting module kernel32.dll, version 5.1.2600.5781, fault address 0x00012afb
In mean while, others applications open fine, like notepad, iexplore, etc... but SOME of my applications don't, with only event log described above. But if we do not restart system, in a few days even cmd.exe stops open, (and all other applications) with same error on eventlog.
I've tried to find 'what' can cause this, but with no sucess. So, and any advice will be welcome.
Thanks in advance.
I think you are running out of resource handles (Window handles). You can verify this by having a look at the system properties in Sysinternals Process Explorer (a better task manager). I think even the default task manager can help out to display a handle count. Then you can identify which application is causing the trouble.
Once you know the application leaking and if it is yours, you can use Rational purify or Boundschecker to drill down to the problem. If you do not have money for these tools you will have to reduce the problem manually a bit by deactivating some features for example and see if the handle count still increases...
Not sure if it is the problem you are experiencing maybe it is completely unrelated. But easy to check. The track is that some app is stealing some global resources as you experience trouble with other applications. Applications like notepad do not use much resources so appear to work fine, heavy apps are more likely to show up the trouble.
Hope it helps.
How can I find what's hanging all new installations on a Windows box?
While testing an installation script on Windows (XP Pro, if it matters) I've run into a situation wherein any and all attempts to install anything on the system hang waiting on who knows what. When the system is restarted, all queued up attempts at installation then go through their exit paths with pop-ups that report the installation is being aborted due to system shutdown having been requested. Of course, reboots do not cure the problem. The system otherwise runs fine.
So... How can I determine what part of the OS I've wedged? (Something in the registry, I suppose, but I'm a real greenhorn when it comes to Windows.) Most likely, something from a preceding install attempt went awry and is now blocking even though I saw no errors reported. Once I figure this out, I want to put in a check for this sort of thing, possibly at both ends of my install scripts, if that seems reasonable.
Thanks for your input.
UPDATE:
Unfortunately for me, rebuilding from scratch to get to the point the system's in now is about 9 hours. I'd like to unwedge it from where it is now rather than reload (again). Procmon seems great but I haven't got SP2 installed, only SP1! -frown- So, other ideas are welcome.
I assume you've tried logging the install to see where things go wrong?
Try rolling back to before things went wrong using "System Restore", if that doesn't solve it and the MSI log files show nothing useful then I'd take the plunge and reload before wasting any more time on it.
That said, if you're developing installers then taking an image of this PC in it's crappy state could be a worthwhile exercise. Some point in the future when you have more time to debug you can try and figure out what the problem is.
P.S. I'm assuming you're asking this question from the point of view of someone developing an installer and not as a tech-support question... otherwise this question should probably be closed as not-programming-related ;)
Try using Procmon to figure out where the installer is having problems, if you set a filter it will report all file and registry activity for that process.