So it looks like this happens only with certain files in a specific folder.

I suggest following:

Copy a file which results on opening in UltraEdit in a not responding UltraEdit to C:\Temp. Create that directory if not already existing.

Try to open the copied file in C:\Temp with UltraEdit as you usually open it.

By the way: How exactly do you open the file in UltraEdit? There are more than 10 methods to open a file in UltraEdit.

Does opening the copied file in C:\Temp also result in a not responding UltraEdit?

If the answer is no, the problem is not the file content. In this case I suggest further to delete the file in original source folder. Then copy the file from C:\Temp to original folder.

Does opening the file in original folder result again in a not responding UltraEdit or does it work now?

When it works now, the problem is most likely solved for this file and the copied file in C:\Temp as well as the folder C:\Temp can be deleted.

In this case I suggest further to open a command prompt with as administrator, run the command chkdsk C: /F and confirm that the Windows check disk tool should be scheduled for execution on next system restart. Restart Windows, wait 10 seconds until the disk check (file system integrity check) starts and wait further until it finished and Windows restarts normally. After Windows restart, open Event Viewer and search in Windows Logs in Application for an entry in column Source by Wininit which is somewhere at top of the list. This event entry contains the summary information of check disk execution and in case of detected errors also the which errors were found and hopefully fixed.

---

In case of opening copied file from C:\Temp results also in a not responding UltraEdit, I suggest to open Windows Task Manager and look on tab Processes how much CPU usage uedit64.exe process consumes. If it is 25% on a computer with 4 cores, UltraEdit is running obviously in an endless loop as using all power of 1 core.

In this case please kill UltraEdit process by selecting it and clicking on End Process, compress the file into a ZIP or RAR archive and send it to IDM support by email with the explanation that opening this file results in a not responding UltraEdit on your machine consuming full power of 1 core which means most likely 64-bit UltraEdit 24.00.0.76 is running into an endless loop.

---

But when not responding UltraEdit is using nearly no CPU power or when just opening the file from original folder results in an endless running loop, it is possible that UltraEdit does not get the file access as requested by UltraEdit and this results in a long delay respectively not responding UltraEdit user interface.

In this case I suggest to download the free tool Process Monitor from Sysinternals (Microsoft) and extract the ZIP file to any local folder of your choice.

Then start Procmon.exe as administrator, select Path contains file name with extension then Include and click on button Add. Next click on button OK. Process Monitor is now running. From the last five symbols on toolbar toggle off with a click on all with exception of filing cabinet symbol with tool tip Show File System Activity.

Press Ctrl+X to clear what Process Monitor already recorded and open the file in UltraEdit which hopefully results again in a not responding user interface and wait up to 2 minutes (look on clock).

Then switch back to Process Monitor, stop capturing by pressing Ctrl+E and look from top to bottom on which processes accessed the file with which command and which type of access and what was the result.

It could be that you see that UltraEdit does not get the file access it wants according to your configuration for example because of NTFS permissions or because of specific file access denied by another process.

---

My last suggestion is opening the properties of the shortcut used to start UltraEdit.

On tab General check if Location of shortcut file is a directory (desktop or start menu) which belongs to your user account or or the all users account.

On tab Shortcut click on button Advanced and make sure Run as administrator is NOT checked.

On tab Compatibility make sure none of the check box options being enabled.

I have never seen before such a file system access log on opening a file with UltraEdit. I was not even aware of the Windows kernel functions QueryAttributeTagFile and CreateFileMapping. I have tried with 32-bit UE v24.00.0.76 on Windows 7 SP1 x64 to see such a file access on opening a file. But I could not find a file open method which results in execution of these functions. So I would be really interested in:

How do you open the file C:\Impact\mcs\t\z_vrbtst.ps?

Perhaps this occurs only when file is opened via SVN. In this case I'm not able to reproduce that because of not having SVN installed at all on my machines.

After no success on reproducing the file open resulting in usage of QueryAttributeTagFile and CreateFileMapping I looked on file open of C:\Temp\z_vrbtst.ps.

The file has a file size of 78705 bytes according to information in row 7. But on opening C:\Temp\z_vrbtst.ps UltraEdit reads first just the last 408 bytes from offset 78297 as it can be seen on row 112. Why? I don't know why the file reading did not start from offset 0 with a 32 KB or 64 KB block as usual.

Was the file already opened in UltraEdit on logging the file system accesses?

I have never seen before that UltraEdit first reads just a few bytes from end of file.

I also can't see a file query which tells UltraEdit that the file C:\Temp\z_vrbtst.ps has a file size of 78705 bytes. That's all very mysterious for me as I have never seen this before on analyzing UltraEdit file access logs.

Is file polling enabled for this file?

On the rows 135 and 136 it can be seen what usually happens first, the entire file contents is read by reading the first 64 KB and next the remaining bytes according to file size most likely for creating the temporary file.

Perhaps there is a problem with the temporary files creation in %TEMP%. It would be interesting to see also what file system accesses occur on temporary file. Modify the Process Monitor filter to log all file system accesses for Path contains z_vrbtst (without file extension) to get also the temporary file accesses displayed.

By the way: The board allows attaching 1 to 3 files with up to 250 KB per file being a ZIP or RAR file. That's the best method to attach a log either in native Process Monitor format or a CSV file compressed with best compression into a ZIP or RAR file.

It is really very strange what happens on your machine.

I don't think another process like an antivirus application is responsible for the not responding UE on file open or change of active file, except the antivirus application is configured to always scan all files on possible threads independent on file extension. However, if you are running an antivirus application I suggest to temporarily disable the on-access scan of the antivirus application and check if UltraEdit is still not responding on opening that file or on switching to another file.

But it looks like this issue depends really on file contents, but not on all the features associated with syntax highlighting.

Does UltraEdit consume the complete processor power of a core when UltraEdit is not responding?

That would be a very clear indication of a bug in UltraEdit which results in UltraEdit is running into an endless loop. Such an issue is usually easy to detect by a developer when having the same file and the same settings, i.e. an email is sent to IDM support with a ZIP or RAR file containing the file opened by you and best the entire directory %APPDATA%\IDMComp\UltraEdit.

Otherwise UltraEdit is waiting for something on nearly no CPU usage by not responding uedit64.exe process which can be also caused by a bug in UltraEdit (multi-thread issue), but is caused most likely by another process running in background.

I suppose that you use projects in UltraEdit and there is a project opened in UltraEdit after starting. I suggest to do following:

1. Make sure that just one instance of UE is running by exiting all other running instances.
2. Close the project when there is one opened. And close also all files.
3. Open Advanced - Settings/Configuration - Toolbars / Menus - Miscellaneous, click on button Clear history and next on button Cancel.
4. Exit UltraEdit.
5. Open with Windows Notepad %APPDATA%\IDMComp\UltraEdit\uedit64u.ini and search for [Open Address Bar]. Remove the entire section, save the file and exit Notepad.
   (I reported some weeks ago that the file names with full path in this section are not removed on using button to clear history, just the count is set to 0 which is not enough.)
6. Restart UltraEdit, press Ctrl+O and open that file. Use Ctrl+O a second time and open another file. Switch between the file tabs of those two files.

Does on last step occur again that UltraEdit becomes not responsive?

Yes, then I agree with your assumption that the encoding of the file in combination with all the modifications made on UltraEdit source code to became a real Unicode aware application is responsible for the hangs of UltraEdit user interface.

By the way:

Which encoding have the files which cause the non responsive UltraEdit and have the other files a different encoding?

I tried to reproduce this issue with creating a file test.uew (ANSI 1252 encoded with DOS line terminators) containing just the single line posted by you with case-insensitive alternate block comment and a file test.txt (ANSI 1252 DOS) containing the posted block with 32-bit UE v24.00.0.76 with everything in configuration set to default. But I failed to reproduce the issue. The file test.txt was opened without any problem and was also correct syntax highlighted as alternate block comment although end of block comment was missing in the file. Another *.txt file not containing IFZ was also opened without any problem. And a third file with extension TMP was opened also quickly. Switching active file worked also well.

However, you have definitely found the bug. So please send the example file together with everything in %APPDATA%\IDMComp\UltraEdit including the wordfiles directory with the wordfile by email to IDM support and report what you have found out regarding running in endless loop by UltraEdit because of case-insensitive alternate block comment.

BTW: There should be only one space in wordfile after string IFZ, but that additional does not really matter. And there should be only one double quote after String Chars = . The typical string character definition is: String Chars = "'. On using just the double quote character as string begin/end character there should be only 1 double quote in the wordfile.