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.
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..
Is there any bottleneck above the physical the cpu and HAL? Or are there multiple ways a process could start under Windows XP, Vista, or 7, that don't invovle CreateProcess at some point?
Given the comment on your question:
Building an Anti-Executable driver, just planning, wondering if controlling createprocess would be enough.
No it wouldn't be enough if security is your concern. There is NtCreateProcess below that one for example. And those aren't the only ones.
The best way provided by the system is a file system filter driver. In fact the WDK comes with samples that require only a moderate amount of change to do what you're asking. Since you asked about XP you can use a minifilter if you can get away with support for XP SP1 and later.
PsSetLoadImageNotifyRoutine and PsSetCreateProcessNotifyRoutine are unfortunately only notifications. So they don't allow to do anything about the event that they notify about. And you really shouldn't attempt to work around this.
In the old times I have seen some clever implementations using SSDT hooks on ZwCreateSection that would exchange the returned handle with one to an executable that shows an error message. Since the executable itself sees the original command line, it can then show a nice error message informing the user that the command has been banned for reasons xyz. However, with Vista and later and even on XP and 2003 64bit (x64), it's going to be harder to write the SSDT hooks. Not to mention that everyone would frown upon it, that it requires quite extensive experience to get it right (and even then it often has flaws that can cause havoc) and that you can forget any certifications you may be aspiring for in the Windows Logo process.
Conclusion: use a file system filter driver to deny access to unwanted executables. With a minifilter the learning curve will be moderate, with a legacy filter I'll recommend you take a few courses first and then start your first attempts.
Looking through a quick disassembly of CreateProcess, it appears that the two main things it does are:
Call NtCreateUserProcess (this is syscall 0xAA) to actually create the process structures in the kernel (PEB, etc.)
Start the new process with a call to NtResumeThread (syscall 0x4F).
The Windows Internals books certainly detail this process very well.
I'm not sure if there are designated hooks in the kernel which would allow you to create your anti-executable driver. It used to be that you could hook the "System Service Dispatch Table" to change how these system calls behaved. But now, technologies like PatchGuard prevent a driver from doing this (and allowing the system to run).
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'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.
Does anyone know ways of partially or fully automating driver test installation?
I am new to driver development and am used to more of a test-driven approach in higher level languages, so moving to the kind of environment where I can't easily test as I go has been a step up for me. I am using Virtual PC for my test environment and currently have to reset it, open device manager, choose the device, click through a bunch of "Are you really sure you wouldn't rather install one of these system drivers" type dialogs, then finally reset the test environment while restarting WinDbg in the host machine just as the test environment is booting up... argh.
After repeating this process many, many times already, surely there has to be a be a better way of doing this? What tools/methods/tricks do commercial driver developers use to run up their driver in a test environment?
Note, this isn't about unit testing drivers, I haven't got to that stage yet or know if it is even possible. This is just about firing up a test environment with WinDbg attached to make sure that some small change I may have done is doing what I expect.
It seems to me that a virtualization software + a "mock objects" (layering) approach (as suggested by Aaron Digulla) + scripts (as suggested by Sergius) can simplify device driver development.
But if you use Visual Studio to develop user-level applications, you can use it for kernel device driver development too with VisualDDK (+ VirtualKD to debug over a named pipe, which is faster than over a virtual COM port), which addresses specifically the annoyances that you mention; from its home page:
... This project brings the simplicity and
convenience of Windows application
development to the driver development
world. No more manual creation of
build scripts, copying of driver
files, installing drivers from INFs,
switching between WinDbg and the
source editor or waiting for seconds
after each step due to the extra-slow
virtual COM port. Just create a driver
project using a convenient Driver
Wizard, select a virtual machine, and
enjoy debugging your driver directly
from Visual Studio. Want to test a
change? Just normally press Shift-F5,
modify your driver, rebuild it and
launch again. VisualDDK will unload
the old driver, install the new one
and load it automatically and quickly.
Bored with WinDbg loading symbol files
for minutes and looking up symbols for
seconds? Just let VisualDDK optimize
this for you using its own DIA-based
symbol engine. Using C++/STLPort in
your drivers? VisualDDK will natively
visualize all STL containers and
strings, as good as Visual Studio does
for user-mode applications. ...
You can write some shell scripts (using sc.exe and devcon.exe) to automate deployment tasks (no opening device manager, clicking on buttons, etc). And make snapshot of the system ready to debug (needn't wait for system boot).
Don't forget to check your driver with DriverVerifier!
Example of my own script :)
sc create FsFilter type= filesys binPath= c:\FSFilterDrv.sys
sc start FsFilter
pause
sc stop FsFilter
sc delete FsFilter
Follow the advice I gave here. Basically, test as little as possible with the real system.
In your case, I've got another tip: Virtual PC is using a virtual hard disk (that's probably a file on your real hard disk).
You don't need to install your driver, you can simply replace the new files in the virtual hard disk. This is often not possible in the running system but in a virtual system, you can open the virtual disk file and change it (since Windows isn't locking the files in it).
I'm not sure about Virtual PC but other emulators come with tools to work with virtual disk images. If VPC can't do it, check out VirtualBox.
It all depends a little on what kind of driver you are writing. But in many cases, writing an appropriate makefile (or something similar) that handles driver installation, start/stop, and launching of a test harness can already be good enough.
I also configure all of my test machines to automatically logon (AutoAdminLogon), map net drives, and launch an appropriate command prompt after startup. Running a specific test is then a matter of typing in a single command only.
One word concerning VirtualPC: VirtualPC is very handy for kernel mode development, but do not forget that it emulates a uniprocessor machine only -- so be sure to regularly test the code on a multiprocessor machine as well. That said, the VHD trick may seem handy, but it somewhat ties you to Virtual PC -- writing appropriate scripts that equally work on VirtualPC as on a real machine therefore seems a better approach to me.
Finally, consider it a shameless plug, but if you are looking for a unit testing framework for Windows kernel mode code, I have written one: cfix.
I think the DevCon utility (described in this OSR Online article) will help you. You should be able to setup batch files that do the job on one click.
It's free to sign up with osronline.com, and you'll probably have to sign up to get to that article. And if you are writing drivers, you WANT to sign up. These guys have been doing this for a long time, and there's a LOT of really good info on that web site.