I'm trying to fire up IIS on my machine, but I've run into a range of issues. I think it boils down to the fact that I can't start the WAS service.
I'm finally at a point where it tells me: Cannot find the file specified.
On the Properties dialog, under Path to executable, it says: C:\Windows\System32\svchost.exe -k iissvcs.
"svchost.exe" is indeed in the System32 directory where it should be. I'm looking for a next step in troubleshooting this issue.
Related
Working with Pure Data, trying to record audio output from a patch I've made, and am 1) unable to create a file within pure data to write to and 2) attempting to use the writesf~ object causes the program to freeze after about two to three seconds. I suspect the two things are related- perhaps the program is attempting to write data somewhere, somehow, but it's going in the wrong place or some such and causing the program to freeze?
I've uninstalled the latest Pure Data release (0.51-1) and installed an earlier stable release (0.5-2) and even tried an alternative called "purr data (latest release)" all with the exact same result on my windows 10 acer laptop: no file created, and program freezes after a few seconds.
I'm testing with this patch:
I first click on the message that reads "open rec.wav" then the start then the stop, and if I take longer than three or so seconds to click on "stop" the program freezes, otherwise nothing at all happens.
I have performed system wide search for the audio file, including the folder that the patch is in, all to no avail.
Any trouble shooting hints will be carefully attempted.
Are you sure you have write-permissions on the target directory?
If your example you use rec.wav which has no explicit target directory (and is just using the "current", so it's hard to tell from outside what this directory would be).
#max-n's answer suggests to use /tmp/foo.wav which is an illegal directory on Windows. Due to a known bug, using an illegal (or otherwise non-writable) path will lock up Pd.
If your "current" directory happens to be your system root (aka C:\), you might well lack the permissions to write there.
You could check by starting the Pd from the cmdline and see whether the terminal spits out any weird errors:
⊞ Win+R
type cmd and hit Enter
in the opening terminal type the full path to your Pd-executable, e.g.:
C:\Program Files\Pd\bin\pd + Enter
(ideally leave out the extension (that is: use .../pd rather than .../pd.exe)
If the problem is indeed a permission problem, you can simply work around it by specifying the full path of the output file (and make sure that it is in a writable directory).
The easiest way to do this is by using a file-selector to choose the output file:
[bang(
|
[savepanel]
|
[open $1(
|
[writesf~]
There might be a reason why the helpfile uses a [delay 1000] to schedule a stop message in a predefined time.
I have the following test InstallScript InstallShield code, which executes correctly in the normal interactive mode, but crashes setup.exe /s (silent) mode on calls to ChangeDirectory that involve any sort of actual depth of directories.
//Note: "C:" ^ "temp" resolves to "C:\temp", but it never successfully
//executes when run silent mode. It works fine in interactive mode, however.
ChangeDirectory("C:" ^ "temp");
//No subsequent code gets executed at this point in silent mode
I'm running this on a Windows 2008 x64 Server in a command window with Administrator privileges. The c:\temp directory exists, and EVERYONE has been granted full control rights to it.
The exit code is -2147213312, which is 0x80042000 in the error guide corresponding to
The installation exited with the abort keyword because the end user
canceled the installation.
What could possibly be going on here? I've tried using the try/catch syntax to examine the error, but the catch block never executes in this case, seemingly asserting that there's no error but instead an abort called?
The Installscript Engine does a lot of stuff behind the scene. It keeps changing the working directory. Thus, it is not very reliable to use ChangeDirectory(). It is surely better to use FULL PATH to all executables and other files. LaunchAppAndWait() too has this trouble. So full path needs to be used without fail.
Further, the Installshield help for ChangeDirectory() clearly mentions the following:
When you are specifying a file in your script, always specify the full
path (using the appropriate InstallShield system variable, for
example, SRCDIR) rather than depend on the current folder having the
appropriate value. The script internally executes code that can change
the current folder, so its value may not be what you expect.
The thing is, results are not reliable. They may work or may not.
We get this errorcode when our recorded .iss file is missing an entry in the .iss response file.
See Creating the Response File for more Details.
Logging an installscript setup didn't give us much information, so we wrote some functions to write to a custom logfile which helped us a lot.
For no reason that I can see, I can no longer run a TortoiseSVN Update on a development directory on my portable Windows XP Professional SP3 machine, getting the error:
Previous operation has not finished; run 'cleanup' if it was interrupted
Please execute the 'Cleanup' command.
If I try running cleanup, I get another error,
cannot process the following paths: cannot move $ROOT_DIR/.svn/tmp/tmp-... to $ROOT_DIR/path/where/thing/should/go: no such file or directory
I have verified that both files exist, and actually from CMD.EXE prompt I am able to issue a MOVE with those two filenames and have it work correctly. It's no use because next time SVN tries to repeat the operation itself after creating a different tmp file name, and while CMD succeeded, SVN fails.
UPDATE: the path lengths are in both cases well below PATH_MAX, target file system is NTFS, and permissions are OK. Maybe I'll now try with FileMon to see whatever TortoiseSVN is really up to.
I tried downgrading TortoiseSVN but to no avail. Other repositories work OK between the same machines.
TortoiseSVN 1.7.9, Build 23248 - 32 Bit , 2012/08/30 18:25:37
Subversion 1.7.6,
apr 1.4.6
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.1c 10 May 2012
zlib 1.2.7
Both server (OpenSuSE Linux 12.2) and client now run the latest version of SVN.
On Windows, I also cannot seem to get any more informative logs or information (I'm not very skilled with TortoiseSVN, I have always used the Linux command line version).
I might delete the local copy and run a checkout, but it's about 2 GB of data, and I'm on a slow connection, so it is really more of a "fly physically to server location and hook a copper Ethernet to the local network there" alternative. I'm reserving that as a sort of last ditch, nuclear option; I'd really rather understand what the problem is, for I fear it might happen again.
UPDATE
I've tried to delete remotely the subdirectory involved, committing the deletion on the server; deleting the subdirectory locally, and emptying the .svn/tmp subdirectory where I found sixteen tmp files, all copies of the one PNG causing problems.
I am still not able to perform any SVN subcommand, getting "Run cleanup!" error; on cleanup; I get a failed attempt to copy a tmpfile to the never-sufficiently-damned .PNG file, which no longer exists anywhere, into a directory that no longer exists anywhere.
I tried recreating the directory locally (but not the file!), no changes.
With FileMon, I traced the source PNG to 8e4c2389cf9d85c8b8ee54d49ea053c752a38187.svn-base in .svn/pristine subdirectory, tried removing it and got SVN complaining. I tried copying it to its intended destination (so that the file-as-it-should-be and the file-as-it-is are identical), no joy.
UPDATE
Well, this is weird. I decided to track everything that TortoiseSVN is doing using FileMon. I could see it checking the wc.db and search the item, checking for it in .svn/pristine (and finding it), copying it (unnecessarily if you ask me...) in .svn/tmp, and finally checking $DESTINATION_FILE (with correct case) using Windows Open() API. And getting PATH NOT FOUND. Yet the file is there, I can see it (and the name is less than 8.3 characters). And why PATH not found and not FILE not found?
Okay, it all boiled down to a directory that had been created remotely with a name ending with space. The file in itself was OK; the directory where it stood was not.
When updating, apparently, the directory got created but the name was shortened by Windows to exclude the final space.
To add to the difficulty of diagnosing, while TortoiseSVN did tell me what the problem was, it did so in the dialog box where the Arial font made the space in \path\to\your \file not clearly recognizable (it was, once I knew where to look, and compared that slash with the others. This one stood a little farther from the letter at its left).
Lesson learned: check really carefully the dialog file name, character by character (note to self: find a way of having it in Courier New if at all possible).
You may have two files in the repository that differ only in case. That's a problem on Windows. See this FAQ for details.
I'm having trouble using macros in my .inf file that I'm using to create my cab, specifically when setting the InstallDir string. If I do something like this:
InstallDir=\<PathToProgramFiles>\MyAppName
then everything works fine. However, if I do this:
InstallDir=%CE1%\MyAppName
then I get the following error when trying to install the cab (double tapping it on my device): "MyAppName was not installed successfully. Please run Setup again."
This only seems to apply to the built-in macro strings. I can use %AppName% without any problems. Maybe there is some registry setting that isn't properly set that would normally resolve the %CE1% macro?
Any ideas about what is going on?
Edit: My device doesn't have a \Program Files directory. It seems the %CE1% macro always resolves to that path and if the InstallDir specified in the inf file doesn't exist (with the exception of the last directory portion then the install fails. Manually creating \Program Files fixed the issue. Since a lot of the devices I'm working with have different paths for their Program Files directory, is there a generic way to get the installer to default to the actual Program Files dir? I guess my only other option is to not specify a path and force the user to choose one?
First, in this link you can find the shortcuts and their meaning (the %C..%), goto appendix B. The Windows CE5 MSDN link.
You can add a Setup Dll to your CAB installaer that will check the directory structure and will create a folder in case it does not exist. You may find this SO question useful.
A warning: If you are targeting regular Windows CE devices, beware where you place the files as it can be to a RAM based file system and then the files will disappear after reboot.
I find increasingly now when I am building a large project, I get the following error.
fatal error C1083: Cannot open
compiler intermediate file:
'C:\Temp\SYS\a03132ex': Permission
denied
It occurs in Visual Studio 2003 and VC6, and I have investigated the potential MSDN reasons and drawn a blank. There is plenty of space on the hard disk, and not that many other programs open that I should be running out of handles. Any ideas, or is it time to re-install windows again. I'm running XP SP3 by the way, and have two large NTFS hard disks with very many files.
Edit: the name of the temp file changes, and I have cleared out the entire c:\temp folder.
I seem to remember from somewhere deep down memory lane that deleting the temporary files created by visual studio for the project fixes this issue (until it pops up again).
The temporary files have the same name as your project. (There may also be something VC/VS related in your home directory if that does not help.)
And if that doesn't help, check if your TMP environment setting doesn't end with a semicolon for example. It should be a fully qualified path as well, not relative.
Edit: I found a topic on the internet about it and there it is said that if you attempt to include a directory instead of a file you can trigger that very same error.
I assume you already verified this, but does the actual C:\Temp\SYS folder have the correct permissions (ie allow all users to read/write files in it)?
You could also check the rights associated with c:\temp and c:\temp\sys (if sys does exist outside the compilation session)
cacls c:\temp
Also, (as suggested here), try setting the compiler flag -Bd under advanced options and inspect the arguments into the compiler. Maybe you meant to specify a path and end up compiling a non-existant file ?
Keep your temp file location simple, for example when I copy projects from my laptop to my office PC the VS2003 project didn’t compile.. The “tmp” system variable was pointing to %USERPROFILE%/TEMP. Visual studio 2003 was giving few "Fatal error C1083: Cannot open compiler intermediate file:" errors
I made a new Temp folder on C drive and change the system variable TMP to "C:/TEMP". Recompiled the program and Voilà no errors!
do not click Rebuild button in complier, click Build button only - this solve my problem
I had exactly the same issue. Disabling the antivirus while building the project solved that issue. A possible permanent solution would be to setting VS's temporary directory somewhere else and telling the antivirus to exclude that directory.