I am trying to test out MVVMLight but the DLLs that come with it are BLOCKED. I have read about it and I am told to click the UNBLOCK in the file property.. but that doesnt exist for me.. Then I found out of a program called STREAMS that is suppose to unblock.. that didnt work... any other idea how to fix this?
Error 7
Could not load the assembly
file:///C:\MIX10-MVVM-Samples\Mix10.MvvmDemo2 -
End\Mix10.MvvmDemo2\Bin\Debug\GalaSoft.MvvmLight.Extras.SL4.dll
. This assembly may have been downloaded from the Web. If an assembly has been downloaded from the Web, it is flagged by Windows as being a Web file, even if it resides on the local computer. This may prevent it from being used in your project. You can change this designation by changing the file properties. Only unblock assemblies that you trust. See http://go.microsoft.com/fwlink/?LinkId=179545 for more information. Mix10.MvvmDemo2
The file contains an alternate data stream that indicates that the content was retrieved from the Internet and is not secure. This is a feature of the NTFS file system, one that's unfortunately well hidden because Explorer has no support for showing their content. You can see them from the command prompt with the DIR /R command option. And type their content with TYPE filename:streamname. And delete them with DELETE filename:streamname
Other tricks is to copy the file to a file system that doesn't support alternate data streams, that slices them off the file. A flash drive for example. Or a zip utility.
Later versions of Windows, I think starting with Win7, has built-in support for this in Explorer. Right-click the file, Properties and click "Unblock".
SysInternals has a great command line utility called Streams. This proved very useful for me.
Streams v1.56 - Enumerate alternate NTFS data streams Copyright (C) 1999-2007 Mark Russinovich Sysinternals - www.sysinternals.com
usage: streams [-s] [-d] <file or directory>
-s Recurse subdirectories
-d Delete streams
Execute the following command in the directory you wish to remove streams from (same effect as copying to USB/FAT32 drive)
streams.exe -d -s *.*
Unblock the zip file first, and then extract the dll's. Actually that's what they instruct to do here.
Only for general understanding. NTFS supports streams (see http://msdn.microsoft.com/en-us/library/aa364404%28VS.85%29.aspx). The full name of a stream is filename:stream_name:stream_type. So one can easy write some additional information about a file in an additional stream of file. If you download a file from the internet Internet Explorer write some simple information in a stream with the name Zone.Identifier. If you have a file test.dll downloaded from the internet you can use
more < test.dll:Zone.Identifier
to see information from the stream. You will see something like
[ZoneTransfer]
ZoneId=3
Unblocking is not much more as deleting of this stream. I recommend you to read http://weblogs.asp.net/dixin/archive/2009/03/14/understanding-the-internet-file-blocking-and-unblocking.aspx for more detaild information
I simply opened the dll file in notepad++ and saved it with a different name.
If it helps anyone, I pulled down two blocked DLLs from TFS.
My solution:
Inside of Windows Explorer, delete the two blocked DLLs.
Inside of TFS, do a 'Get Specific Version' operation on the folder, and make sure that 'Overwrite all files even if the local version matches the specified version' is checked so that you will pull down fresh copies of the deleted DLLs.
Rebuild your solution.
Related
I need to be able edit the content of index.dat file programmatically (C:\Documents and Settings\Username\Cookies\index.dat). More precisely I need to modify it in order that index.dat for one user can be used for a different user name. Is there any documentation out there for this kind of binary file?
Pasco (http://www.foundstone.com/us/resources/proddesc/pasco.htm) is a free index.dat parser that comes with the source code.
Docs will be hard to come by - Microsoft has never publicly documented the structure of the the structure of this file. That said, you can find docs on the web such as the one mentioned above.
However, note that IE keeps close tabs on this file. The file is locked while IE is running (meaning, you can open/read it in some modes but not in others) and you can certainly not write to it.
One method that might still work is to boot-up in safe mode and then assign yourself administrator rights and then see if you can find the files to delete them.
The method I now use is to create a batch file to rename the subfolder below the folder containing the index.bat files and to then only copy the folders back to the original location that don't contain these files but the resultant batch files needs to be run from a separate windows account that has full administrator permissions.
The freeware code editor PSPad will allow you to view and to edit the contents of all of the index.dat files on your computer in hexadecimal form. This is done by replacing all of the digits in the first eight columns with zeros. This removes all of the information contained in the files.
It's a tedious process, requiring holding down the "0" (zero numeric key) as all of the edits are made, but anyone then accessing any of the index.dat files will get no information.
IE must be closed when doing this or you may receive an error message when attempting to save the modified file(s).
My windows co-workers were asking me if I could modify my non-windows binary files such that when their "Properties" are examined under Windows, they could see a "Version" tab like that which would show for a Visual Studio compiled exe.
Specifically, I have some gzipped binary files and was wondering if I could modify them to satisfy this demand. If there's a better way, that would be fine, too.
Is there a way I could make my binaries appear to be exe files?
I tried simply appending the VS_VERSION_INFO block from notepad.exe to the end of one of my binaries in the hope that Windows scans for the block, but it didn't work.
I tried editing the other information regarding Author, Subject, Revision, etc. That doesn't modify the file, it just creates another data fork(what's the windows term?) for the file in NTFS.
It is not supported by windows, since each file type has their own file format. But that doesn't mean you can't accomplish it. The resources stored inside dlls and exes are part of the file format.
Display to the user:
If you wanted this information to be displayed to the user, this would probably be best accomplished with using a property page shell extension. You would create a similar looking page, but it wouldn't be using the exact same page. There is a really good multi part tutorial on shell extensions, including property pages starting with that link.
Where to actually store the resource:
Instead of appending a block to the file, you could store the resource into a separate alternate data stream on the same file. This would leave the original file stream non corrupted on disk and not cause its primary file size to change.
Alternate data streams allow more than one data stream to be associated with a filename. Each stream is identified by a colon : at the end of the filename and an identifier.
You can create them for example by doing:
notepad test.txt:adsname1
notepad test.txt:adsname2
notepad test.txt
Getting the normal Win32 APIs working:
If you wanted the normal API to work, you'd have to intercept the Win32 APIs: LoadLibraryEx, FindResource, LoadResource and LockResource. This is probably not worth the trouble though since you are already creating your own property page.
Can't think of any way to do this short of a shell extension. The approach I've taken in the past is a separate "census" program that knows how to read version information from any kind of file.
Zip files can be converted into exe files by using a program that turns a zip file into a self-extracting zip (I know that WinZip does this, there are most likely free utilities for this also; here's one that came up on a search but I haven't actually tried it). Once you've got an exe, you should be able to use a tool like Resource Hacker to change the version information.
It won't work. Either Windows would have to know every file format or no file format would be disturbed if version information were appended to it.
No, resource section is only expected inside PE (portable executable; exe, dll, sys).
It is more then just putting the data inside the file, you have a table that points to the data in the file header.
What you can do if you have NTFS drive, is to use NTFS stream to store custom properties this way the contact of the binary file will remain the same, but you will need to use a custom shell extension to show the content of the stream.
We're providing a zip file of our application for testing and the same zip file on two separate machines is extracted differently. One will extract all files, the other will extract all but the executables (.exe and .msi specifically).
We're going to have to tell our customers something other than 'use WinZip' (or 7zip, or whatever)
When I look at what is happening using ProcessMonitor, I see that the explorer.exe process is creating each file, then deleting it. WTF?
The two systems are Windows Server 2003 with SP2. Surely there is a setting that we can point to that explains why this happens.
**UPDATE 1****
I enabled/disabled virus scanning with no noticeable effect.
My guess is it's a virus scanner or other "anti-malware" bit of kit - possibly something to do with group policy?
There was a security patch/setting that one machine had that the other didn't. The zip file needed to be 'unlocked' by looking at the properties.
Until then, no executables/dlls would be extracted from the file.
IIRC, ProcessMonitor has the option to show the stack for the delete event. You would need Windows symbols (or a configured symbol server), but the function names should give you an hint why the executables are deleted.
I have a Windows service application on Vista SP1 and I've found that users are renaming its executable file (while it's running) and then rebooting, thus causing it to fail to start on next bootup because the service manager can no longer find the exe file since it's been renamed.
I seem to recall that with older versions of Windows you couldn't do this because the OS placed a lock on the file. Even with Vista SP1 I still cannot copy over the existing file when it's running - Windows reports that the file is in use - makes sense. So why should I be allowed to rename it? What happens if Windows needs to page in a new code page from the exe but the file has been renamed since it was started? I ran Process Monitor while renaming the exe file, etc, but Process Mon didn't report anything strange and just logged changing the filename like any other file.
Does anyone know what's going on here behind the scenes? It's seem counter intuitive that Windows would allow a running process' filename (or its dependent DLLs) to be changed. What am I missing here?
your concept is wrong ... the filename is not the center of the file-io universe ... the handle to the open file is. the file is not moved to a different section of disk when you rename it, it's still in the same place and the part of the disk the internal data structure for the open file is still pointing to the same place. bottom line is that your observations are correct. you can rename a running program without causing problems. you can create a new file with the same name as the running program once you've renamed it. this is actually useful behavior if you want to update software while the software is running.
As long as the file is still there, Windows can still read from it - it's the underlying file that matters, not its name.
I can happily rename running executables on my XP machine.
The OS keeps an open handle to the .exe file,. Renaming the file simply changes some filesystem metadata about the file, without invalidating open handles. So when the OS goes to page in more code, it just uses the file handle it already has open.
Replacing the file (writing over its contents) is another matter entirely, and I'm guessing the OS opens with the FILE_SHARE_WRITE flag unset, so no other processes can write to the .exe file.
Might be a stupid question but, why do users have access to rename the file if they are not suppose to rename the file? But yeah, it's allowed because, as the good answers point out, the open handle to the file isn't lost until the application exits. And there are some uses for it as well, even though I'm not convinced updating an application by renaming its file is a good practice.
You might consider having your service listen to changes to the directory that your service is installed in. If it detects a rename, then it could rename itself back to what it's supposed to be.
There are two aspects to the notion of file here:
The data on the disk - that's the actual file.
The file-name (could be several or none) which you can give that data - called directory entries.
What you are renaming is the directory entry, which still references the same data. Windows doesn't care about your doing so, as it still can access the data when it needs to. The running process is mapped to the data, not the name.
I would like to know who is locking a file (win32). I know about WhoLockMe, but I would like a command-line tool which does more or less the same thing.
I also looked at this question, but it seems only applicable for files opened remotely.
Handle should do the trick.
Ever wondered which program has a particular file or directory open?
Now you can find out. Handle is a utility that displays information
about open handles for any process in the system. You can use it to
see the programs that have a file open, or to see the object types and
names of all the handles of a program.
handle.exe
http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx
THis has helped me sooooo many times....
Download Handle.
https://technet.microsoft.com/en-us/sysinternals/bb896655.aspx
If you want to find what program has a handle on a certain file, run this from the directory that Handle.exe is extracted to. Unless you've added Handle.exe to the PATH environment variable. And the file path is C:\path\path\file.txt", run this:
handle "C:\path\path\file.txt"
This will tell you what process(es) have the file (or folder) locked.
In my case Handle.exe did not help.
Simple program from official Microsoft called Process Explorer was useful.
Just open as administrator and press Ctrl+f, type part of file name it will show process using file.
Handle didn't find that WhatsApp is holding lock on a file .tmp.node in temp folder.
ProcessExplorer - Find works better
Look at this answer https://superuser.com/a/399660
Computer Management->Shared Folders->Open Files
I have used Unlocker for years and really like it. It not only will identify programs and offer to unlock the folder\file, it will allow you to kill the processing that has the lock as well.
Additionally, it offers actions to do to the locked file in question such as deleting it.
Unlocker helps delete locked files with error messages including "cannot delete file," and "access is denied." Video tutorial available.
Some errors you might get that Unlocker can help with include:
Cannot delete file: Access is denied.
There has been a sharing violation.
The source or destination file may be in use.
The file is in use by another program or user.
Make sure the disk is not full or write-protected and that the file is not currently in use.